feature-tracker-mcp

A project-agnostic feature and decision tracker, built for the case where one person is directing several AI coding sessions at once and has become the bottleneck.

The problem it solves is not "track features." It is: you have several tracks in flight, each session is blind to the others, decisions surface constantly, and reading everything is the job. Most of those decisions are mundane and delegable. A few are genuinely yours. Today there is no mechanism separating them, so you read all of it.

This is the mechanism.

Table of Contents

• Roles

• What exists today

• The shape

• Verbs

• Modes

• The spine: one database per project

• Categories

• Gates: the approval queue

• Counts and convergence

• Stop conditions

• Checkpoints, pausing, and summaries

• Why this is not in git

• What will break it

• Build order

Roles

The point of the split is that the second row is currently the human's job, and almost none of it needs to be.

The shape

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

Two properties do the work: the database is the state, so nothing depends on a model remembering; and gates block, so "yes, proceed" is a mechanism rather than a message you had to be present to catch.

What exists today

Honest split, because the rest of this document specifies a system that is only partly built.

Working now — 8 MCP tools, verified end to end against a real database:

Specified but not built: every slash command in the next section, continuous capture, the execution loop, and the generator that renders the markdown tracker back out of the database.

Verified against a real project. 75 features imported from an existing 387-line markdown tracker with every id preserved — DIP-16, GLG-1, UA-11 and the rest still resolve, because they are cited in commit messages and worktree names and reallocating them would orphan that history. Category counters were advanced past the highest imported id, so nothing already in use can be handed out again.

Verbs

Each is a skill, so each is also a slash command. None of these are built yet — they are the intended surface over the tools above.

/standup, /tracker-table and /gates are read-only and never consume a turn of work.

Modes

Ideation. A dialog whose by-product is a populated backlog. As features are invented they are proposed into the database immediately, each one presented to you to agree or alter — nothing lands silently. This is how the queue gets filled.

Execution. A category's features are driven to completion one after another in priority order. ChatGPT selects the next item, briefs the coding session, reviews what comes back, and either accepts it or sends it round again.

Continuous capture. The mundane part, and the reason the list stays true. Every substantive turn — in any session — is examined for what it implied: a new table, a guardrail, a CHECK constraint, a risk needing mitigation, a sub-feature nobody named. Each becomes a proposed row. The alternative is what happens today: it is mentioned once, scrolls away, and is rediscovered expensively later.

Capture runs on turns that changed files or reached a conclusion. Most turns imply nothing, and running it on all of them is how you get a backlog nobody reads.

The spine: one database per project

Each project gets its own Postgres database, created on first use and named from the project's git remote (so every worktree and every clone of the same project agree on the same tracker).

kind is one of feature, guardrail, schema, risk, mitigation. status runs proposed → agreed → in_progress → done, or dropped.

Ids are allocated atomically by the database. This is not a detail — it is the fix for a real, recurring class of bug. Two sessions independently reading a file, seeing the next free number and both taking it produces duplicate migration 016s and clashing issue numbers. A counter incremented inside a transaction makes that structurally impossible.

Every event records the git commit, branch and tree. A feature proposed against a commit that has since been rewritten is a different claim from one proposed against HEAD, and without the stamp nobody can tell the difference later.

Categories

Categories replace the informal notion of a "track" and are generated as features are logged rather than configured up front. Proposing a feature under a new category creates it, with its own id prefix and counter — so DIP-17 and GLG-1 coexist without either colliding or being centrally administered.

Gates: the approval queue

A gate is a decision the working sessions must not take alone.

Raising a gate blocks the session that raised it. Gates queue in one place, you approve, alter, or reject, and the session resumes. That is what turns "this will cost $40, are you good with that?" from a message you had to be watching for into a queue item that waits.

Counts and convergence

Progress is reported as two movements, never a ratio:

3/14  ->  5/16     +2 agreed, +2 surfaced

The numerator is consensus and measures convergence. The denominator growing is healthy — new items mean real disagreement was found that had been there all along, unstated.

A percentage inverts that. 12/16 -> 12/20 reads as 75% -> 60%, a drop, when nothing regressed and two genuine issues were named. A single ratio punishes exactly the behaviour the system exists to produce, so it is never shown.

Stop conditions

Stall is judged on the numerator alone. Items surfacing while nothing gets agreed is circling, and reporting that as progress is the easiest way to lose an afternoon.

Checkpoints, pausing, and summaries

Every two turns the loop stops and reports:

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

You can say pause at any point and get the summary immediately, without waiting for the checkpoint. Nothing runs unattended for longer than you allow — autonomy starts at two turns and lengthens only once it has earned it.

Why this is not in git

The tracker was previously a markdown file. In one recent week it took 115 commits from concurrent worktrees, and the history contains hand-resolved numbering collisions. A single file under version control is already a contention point at human write rates; adding automated per-turn writes from several sessions would make it unusable.

So the database is canonical and the markdown becomes generated output, regenerated on demand and excluded from version control.

The consequence to accept deliberately: git history was the audit trail. feature_event replaces it — append-only, stamped with actor and commit — and that replacement is a requirement, not a nicety. Otherwise you trade merge conflicts for amnesia.

Any project-level instruction naming the markdown file as canonical has to be rewritten in the same change. Sessions obey those instructions; leave one pointing at the old file and they will keep writing to something nobody reads.

What will break it

Proposal spam. Per-turn capture across several tracks can generate hundreds of low-value rows, and then you are reading a backlog instead of transcripts — the same problem wearing different clothes. The bar is explicit: record only what would otherwise be lost, is actionable, and is not already covered. Deduplication is mandatory, because two sessions independently noticing the same missing constraint is the normal case, not the edge case.

Reading the wrong tree. A worktree is a separate checkout. Point a session at the wrong one and it will report your files as missing and your changes as unmade — confidently, and in a way that reads as a finding about the code rather than a misconfiguration. Every operation records the tree it read, so the mismatch is visible before anyone acts on it.

A manager that narrates instead of computing. Counts are computed from the database and cannot be eloquent about something untrue. Summaries written by a model can. Where the two disagree, the table wins.

Autonomy outrunning attention. Compounding errors get expensive fastest when nobody is reading. Gates and checkpoints exist for this, and the default interval is deliberately short.

Build order

1. category, feature, feature_event, gate; per-project database creation; atomic id allocation

2. MCP tools: propose, list, update, table, history, gate raise/list/decide

3. Continuous capture, with the bar and deduplication, plus the agree-or-alter review queue

4. /standup across tracks, including uncommitted work — commits alone miss where the work actually is

5. Gates blocking sessions

6. /ideate

7. Execution loop driving a category to completion in priority order