Comparison
sitrep vs Backlog.md
Backlog.md is one of the strongest tools in this space: free, open-source, local-first, markdown-native, with an MCP server - the same values sitrep holds. The difference is the job. If you want a task board, Backlog.md is the better pick - a task manager is exactly what sitrep refuses to become.
Disclosure: this page is written by the maker of sitrep. Read the framing with that in mind - and note that where the honest answer is "use Backlog.md", this page says so.
The one-sentence difference
Backlog.md gives you and your agents a structured task format to author into - tasks live as markdown files in the repo, move across a kanban board, and travel through git. sitrep is an AI project status dashboard: a state layer on top of the markdown your AI agents already generate - it authors nothing and asks you to author nothing.
Put differently: with Backlog.md, the source of truth is tasks you created. With sitrep, the source of truth is the plans, decision logs and progress notes your agents already wrote - it parses status, phases, open decisions and due dates out of them, across every project at once.
Side by side
| sitrep | Backlog.md | |
|---|---|---|
| What it is | AI project status dashboard - a passive state layer over existing files | Git-native task manager: CLI plus kanban board, tasks as markdown files in the repo |
| Format demanded | None - parses the organic markdown agents already write | Its own task file format; tasks are authored into it |
| What it reads | Plans, analyses, decision logs, progress notes - files nobody structured for a tool | Its own tasks and docs |
| State surfaced | Status, phases, open decisions, due dates and staleness | Task status on a per-repo board |
| Scope | Cross-project - one overview across every repo and workspace | Per-repo |
| Writes to your files | Three guarded state operations in the document’s own convention; nothing else, ever | Creates and updates its own task files |
| Agent integration | MCP server exposing parsed state, read-only first | MCP server for task management |
| Sharing and mobile | Planned: read-only, end-to-end-encrypted mirror and share links | Git-based sharing; local web UI bound to 127.0.0.1, no mobile |
| License and price | Commercial desktop app, in development | Free, MIT-licensed open source |
| Local-first | Yes - no account, no network, no telemetry by default | Yes - no account, no telemetry |
When to choose Backlog.md
- You want a structured task board that both you and your agents create and update tasks on, inside the repo, versioned by git.
- Your workflow is one repo at a time, and a per-repo board matches how you work.
- You want free, MIT-licensed open source you can read, fork and extend.
- Explicitly decomposing work into tasks is a discipline you want, not a friction you resent.
A task manager with its own authored format is on sitrep's anti-roadmap permanently - that job is Backlog.md's, and it does it well.
When to choose sitrep
- The state of your work already lives in organic markdown - plans, analyses, decision docs your agents produced - and authoring a parallel task structure would just be a second source of truth to maintain.
- You run several projects and need one overview: what moved, what is stalled, what is waiting on a decision - across all of them, newest activity first.
- You care about staleness: which docs claim things the repo has since moved past.
- Re-entry is the pain - opening a cold project after weeks and spending the first fifteen minutes reconstructing where things stand.
Using both
These tools are complementary, not substitutes. Backlog.md is an authored task layer inside a repo; sitrep is a passive state layer across repos. If your agents work Backlog.md tasks and also write plans and decision docs, it sits above both, reading whatever markdown is there. Nothing about adopting one forecloses the other, and they share the same posture:local-first, no account, no telemetry.
sitrep is in development, launching first on macOS. Local-first - your files never leave your machine.