Backlog.md Alternatives: When Your Tasks Should Leave the Repository

Look for a Backlog.md alternative when the people or tools that need your tasks are no longer all inside the repository. Backlog.md turns a folder into a project board made of plain Markdown files, with a CLI, a terminal board, a local web board and an MCP server, so coding agents such as Claude Code, Codex and Gemini CLI can plan and update work right next to the code. That is exactly right when the readers of the backlog are you and your agents. It gets awkward when a product manager, a client or a teammate without the repository needs to see or change the work, when you also work through Claude or ChatGPT in the browser, or when you want permissions per person rather than per repository. Then the choice is between a hosted tracker with agents built in and a shared board that every AI app can reach.

What Backlog.md does well

It is worth being clear about what you would give up. The Backlog.md repository↗ (opens in a new tab) describes a local-first, MIT-licensed tool with no server, no account and no telemetry. Every task is a .md file in a project folder such as backlog/, and you install it with npm, Bun, Homebrew or Nix.

• Review before code. Its recommended agent workflow has three checkpoints: review the task spec and acceptance criteria, review the implementation plan the agent writes into the task, then review the code, one task per agent session and one pull request per task.
• Structure agents can follow: acceptance criteria, a reusable Definition of Done checklist added to every new task, milestones, and dependencies that show what a task waits on.
• More than tasks. The CLI reference↗ (opens in a new tab) covers documents and decisions too, and backlog search searches across all three.
• Two ways in for agents. backlog init can write a short instruction file that tells agents to run backlog instructions overview, or configure an MCP connector for Claude Code, Codex, Gemini CLI, Kiro or Cursor.
• Scriptable output. Read commands support versioned JSON with --json, for scripts and integrations.

npm i -g backlog.md
backlog init "My Project"
claude mcp add backlog --scope user -- backlog mcp start

And because the tasks are files in Git, the history of every task is the Git history of the repository. For a developer working with agents in one codebase, that is hard to beat.

Where the repository model stops

The same design choices set its limits. None of these are flaws; they follow from keeping everything in the repository.

• Who can see it. The web board listens on 127.0.0.1 and, per the README, is not reachable from other devices on the LAN or VPN. Anyone else sees the backlog by cloning the repository or reading it on your Git host.
• Who can change it. Access is repository access. Someone who can push can edit any task; someone who cannot push cannot comment on one. There is no role for “can comment but not move.”
• Which assistants can reach it. Agents that run where the repository is checked out can use the CLI or the local MCP server. Claude or ChatGPT in a browser tab cannot.
• Who did what. Git records who committed. If an agent commits under your name, its changes and yours look the same unless you keep them apart yourself.
• More than one repository. The backlog lives in one project folder. Work that spans several codebases, or is not code at all, needs one folder per project or a separate home.

The alternatives, by what you need

Stay local, but let a tool run the agents

Vibe Kanban runs coding agents from a kanban board, each in its own git worktree with a diff to review. Its company closed in April 2026 and it continues as community-maintained open source, with local workspaces still working. It is a different kind of tool from Backlog.md: an orchestrator rather than a task store. Vibe Kanban alternatives covers where it stands now. If you want tasks in the repository but a lighter model, Claude Code tasks vs Beads vs a shared board compares the options.

Move to a hosted tracker with agents built in

If the team already uses Linear or Jira, both now let you hand work to AI agents inside the tracker: delegating Linear issues to an installed agent↗ (opens in a new tab) or to Linear Agent, and assigning Jira work items (formerly issues) to Rovo agents and third-party agents. You get per-person permissions, a hosted board everyone can open, and activity history. You also take on a full tracker, with the configuration that comes with it. Rovo vs Linear agents compares the two, and Linear vs Jira compares the trackers themselves.

Use one shared board for people and every AI app

fenbs sits between the two. It is a web app with one kanban board that people and AI apps read and update over MCP: Claude Code, Codex, Cursor and Copilot in the editor, and Claude or ChatGPT in the browser through a custom connector. Each person holds a role on the board, and each assistant connection acts as the person who approved it, narrowed by the scopes they ticked. History records every change and who made it, a person or which assistant, such as “Claude via” that person.

Several Backlog.md ideas have a direct counterpart, and some do not:

• Task file → a task with a kind (feature, enhancement or bug), a priority from 1 to 10, a note for the problem and a plan for how it will be done.
• Acceptance criteria and Definition of Done → the task’s plan, plus a test status and test notes saying what was checked and what was not.
• Decisions → the Decisions and rules page. A rule is a decision that holds from now on; rules come first in every assistant’s AI context. People decide and sign off; assistants can record a person’s decision or ask an open question, never decide.
• backlog instructions overview → fenbs_get_context, which returns the rules, the project’s Where we left off, what is in progress and what is waiting on you.
• Statuses, which default to↗ (opens in a new tab) To Do, In Progress and Done and can be changed in the config file → four fixed lanes: To Do, Next Up, In Progress, Completed. You cannot add columns.
• Milestones and dependencies → no equivalent. Tasks can be linked as related, but fenbs has no milestones, epics or blocking dependencies.
• Files in Git → a hosted service. Your tasks are not in the repository, and there is no offline mode.

Who should stay with Backlog.md: a developer, or a small team that all works in the repository, who wants tasks versioned with the code and no service to sign in to. Who should pick fenbs: a team that includes people who never open the repository, or anyone working across several AI apps who wants the rules, the decisions and where they left off in one place.

Moving a backlog over

Backlog.md makes leaving easy. backlog board export writes the board as a Markdown report, and backlog task list --json gives you every task as data. In fenbs, Add many next to + New task accepts a pasted Markdown list: indented lines under an entry become that task’s note, and a line that starts with bug:, feature: or enhancement: sets its kind. Everything is previewed before anything is created. Move the open tasks and leave the completed ones in Git, where their history already is.

You can also keep both. Let Backlog.md hold the fine-grained agent tasks inside one repository, with their acceptance criteria and plans, and let the shared board hold what the team agreed to build, the rules every assistant follows, and where each piece of work stands.