An issue tracker for Claude Code: tracking work when agents write it

An agent can finish a task in about the time it takes to read the ticket you wrote for it. That is the part that breaks the board.

Two moments used to put a human's hands on an issue tracker: you picked something up and moved it to In Progress, then you finished and moved it to Done. Both survived as habits because they sat either side of hours or days of work. Take the work out of the middle and neither has anything to hang on. Most advice about setting up an issue tracker for Claude Code stops at "connect an MCP server", and on its own that makes the staleness worse rather than better.

The bottleneck moved and the columns did not

A participant quoted in DORA's March 2026 write-up of its 2025 research says: "Reviewing [another's] code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed…" The authors' own summary of the macro finding is that "higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability".

Developers put it less carefully. On the August 2025 Hacker News thread for a project-management system built for Claude Code, stavros stated the constraint as arithmetic: "the question for me isn't 'how many agents can I run in parallel?', but 'how many changes can I review in parallel?'". A June 2026 analysis puts the operational version as "review queues, CI capacity, flaky environments, branch policy" and the attention needed to decide what merges (Developers Digest).

What that does to the shape of a board has had less attention.

To Do and In Progress were where a human declared intent, and intent is now cheap. In Review and Ready for QA are the only states where a person is still the constraint, so they are the only ones left carrying information.

What an issue tracker for Claude Code has to do differently

Three properties follow, and each is testable.

Status has to be derived from something the work already produces. A branch, a pull request, a review, a merge — each is a fact git already holds. Asking anyone, human or agent, to retype it into a status field creates a second copy that drifts faster the faster the work goes.

The review-adjacent states have to be real states. If your board runs To Do, In Progress, Done, every PR waiting on a human collapses into In Progress and In Progress stops carrying information. Survivable at three things in flight. Not at eleven.

The agent writes to the record but does not get the verdict. This is the part the MCP integrations tend to get wrong.

Why bolting on an MCP server does not fix it

The obvious move is to hand the agent the board and let it keep its own card current. That relocates the staleness rather than removing it: the agent reporting on the work is the agent that did the work.

jing-ny put it well in the June 2026 Hacker News thread for a tracker built for human-AI collaboration: "'Done vs looks done' is partially who is accountable for calling it done, and the trap is the agent that did the work also often declaring it done." The suggested fix is a rule rather than a tool: "Reviewer is never the author."

Anthropic's own framing is narrow. The Claude Code docs describe MCP as what to reach for "when you find yourself copying data into chat from another tool, like an issue tracker or a monitoring dashboard" (code.claude.com). It is an access mechanism, not a truth mechanism. A tracker that reads an agent's update_task call as evidence of progress has swapped an unreliable human habit for a confident machine one.

So: the agent writes what it did, git says what state that leaves the work in, a person decides what merges.

The mechanism, concretely

We build one of these, so read it as illustration rather than recommendation.

Kevta ships an MCP server on both plans, authenticated with a bearer token you create in your profile and can scope to a single board. It exposes nine tools: list_workspaces, list_projects, describe_board, list_tasks, get_task, create_task, update_task, add_comment and close_task. The one doing disproportionate work is describe_board, which returns the board's fields, types and valid options, so an assistant writes your custom columns from the real schema instead of guessing. Setup is one claude mcp add --transport http line, documented at /docs/mcp.

The status side deliberately does not run through the agent. Every issue hands out its own branch name in the form feature/MS-42-refactor-router, type prefix set per board, title slug truncated at 50 characters. When a pull request appears, Kevta scans the branch ref, PR title, PR body and commit messages for the board key and matches it back. No linking step, no magic word — which matters more with an agent than a person: a person forgets a convention occasionally, an agent that never learned it forgets every time.

Then events move the issue. Of the eight rules a new board seeds, five ship enabled — branch pushed to In Progress, PR opened to In Review, marked ready to In Review, approved to Ready for QA, merged to Done. Three of those five land on review-adjacent states, which is the table above expressed as defaults. The branch-pushed rule only fires when the issue is still To Do, and the three reverse transitions ship off, because dragging finished work backwards should be a decision rather than a default. Which git events are worth binding at all is its own argument. A rule whose target status does not exist is never seeded, so renaming columns in board settings is safe.

What this does not fix

We are not first. Linear publishes an official remote MCP server at https://mcp.linear.app/mcp whose "interactive setup flow uses OAuth 2.1 with dynamic client registration" (linear.app/docs/mcp) — a better auth story than a bearer token, on a more complete product. If you are already on Linear, none of this is a reason to move.

Kevta has no AI features: no agent runner, no summarisation, no review assistance, no ticket generation. There is an MCP server, a GitHub integration and a board. No importer or export either, so a live backlog elsewhere is an argument for leaving it there.

And a tracker cannot tell you whether the code is right. The most it can do is say truthfully that eleven things are waiting on a person — a smaller claim than most tools here make, and the only one worth trusting. If your answer is "then review fewer things", you may not need a tracker at all: one person on one repository already has a review queue, and GitHub calls it the pull requests tab.

The one place effort still pays off is the ticket, since it is now read by whatever executes it. That is a different piece of writing.

If this is how your week goes, Kevta is in beta and you can join the waitlist — an early invite, a founding-member price at launch, and a direct line to shape what we build next.