feature-tracker-mcp

feature-tracker-mcp

Enables coordinating multiple AI coding sessions by tracking features, decisions, and approval gates in a per-project Postgres database, with atomic IDs and commit-stamped append-only history.

Category
访问服务器

README

feature-tracker-mcp — "oz"

A project-agnostic tracker for the case where one person directs several AI coding sessions at once and has become the bottleneck.

The problem is not "track features." It is: several tracks are 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. Nothing separates them, so you read all of it.

Each project gets its own Postgres instance in a .oz folder — the project owns its tracker outright.

Table of Contents

The model

Goals are objectives, not filing labels. Each carries what is being achieved, what done means, what is deliberately excluded, and what constrains it. A worker reads its goal before starting and declines work that falls inside the non-goals — that is the difference between executing a queue and pursuing an objective.

Features belong to exactly one goal. Ids are allocated atomically (DIP-17, GLG-4) and never change, so anything citing one in a commit message keeps resolving. They carry acceptance criteria, dependencies, and a parity record.

Gates are decisions a session must not take alone — architectural, install, spend, irreversible. Raising one banks the question and moves on; the principal answers a round of them in one sitting.

Parity is tracked across eight dimensions, because work is only done when it is done in all of them: code, unit tests, functional tests, documentation, screens, builds, infrastructure, features.

Studies are investigations whose deliverable is a document and a decision. Pre-registered, and allowed to conclude "do not build this".

Commands

Driven through the /oz skill.

Working

Command Does
/oz next [goal] What can be worked now — not done, nothing it depends on outstanding
/oz blocked [goal] What is waiting, and on what
/oz task <goal> Drive a goal's features to done, here
/oz start Spawn the backlog maintainer and a worker per goal, each in its own worktree
/oz standup Cross-track state, including uncommitted work per worktree
/oz pause · /oz resume · /oz stop Broadcast to every worker, including ones not yet running
/oz workers Who is alive, how long since each was heard from, what each holds

Shaping the work

Command Does
/oz refine goals Draft and record every unrefined goal in one pass; gate what the docs cannot settle
/oz refine features Give every open feature acceptance criteria in one pass
/oz goal Define a new goal — the conversation produces the name
/oz review [id] Work through a derived checklist a page at a time
/oz boundaries What the project is not
/oz design <goal|feature> Invention, ending in one checkpoint
/oz study <question> Investigate; deliverable is a document and a recommendation
/oz add [text] Record something that would otherwise be lost
/oz link <id> <depends-on> Record a dependency

Decisions and reporting

Command Does
/oz questions The question round — every pending decision, answered in one sitting
/oz watch Alert this session when a question is raised
/oz gates · /oz approve · /oz reject The gate queue
/oz status · /oz table · /oz history Counts, items, the append-only record
/oz parity [goal] · /oz scan <dimension> Coverage, and the cheap probe that populates it
/oz goals · /oz prune Goals and hygiene

Agents

Agent Does
oz-worker One per goal, own worktree. Claims, builds, evidences, releases. Refines its own items and gates only genuine forks
oz-backlog What a worker structurally cannot: dependencies across goals, cross-goal duplication, staleness
oz-capture Per turn, cheap model. Records what a turn implied that would otherwise be lost
oz-triage Dedups; splits what peers can settle from what only the principal can
oz-study Investigates, writes it up, links what it spawned and killed

No agent may call gate_decide. An agent approving its own gate makes the mechanism theatre.

Install

git clone https://github.com/spe-investigator/feature-tracker-mcp.git
cd feature-tracker-mcp
.\install.ps1

Builds, copies the /oz skill and the agents into ~/.claude, and registers the server. Requires Node 18+ and Docker; the database is created in the project's .oz folder on first use, and Docker is started automatically if it is not running.

Design notes

The database is the state, and the bus. Sessions cannot see each other, so coordination goes through Postgres rather than messages: a message is lost if its recipient is not running, and unauditable afterwards. Messaging is at most a doorbell.

Ids are allocated atomically. Two sessions reading a file, seeing the next free number and both taking it is how duplicate migration numbers happen. A counter incremented inside the inserting transaction makes it impossible.

Claims are leases, not flags. A worker that dies holding a flag blocks its feature forever; a lease expires and the work returns to the pool.

Counts are two numbers, never a ratio. The numerator is what converged; a growing denominator means real work was found. 12/16 → 12/20 reads as 75% → 60% — a drop — when nothing regressed and two genuine issues were named.

Standup reads working trees, not just commits. Measured here: every worktree reported zero commits ahead while two held real uncommitted work — a new crate in one, four untracked files in another. A standup built on git history calls active tracks idle.

Rejection means two things. "Not for this goal" is a routing error and the feature is moved; "not wanted" is a decision about the project. Only the second suppresses re-derivation. Every refusal keeps its rationale, and accumulated they define what the project is not — the difference between "no" and "no, because we decided X".

Drafting is derivable; decisions are not. Refinement is a batch pass over everything, with gates raised only for what the documents cannot settle. A flow that asks a question per item spends attention on the part that needed no input.

Studies are pre-registered. Method, decisive evidence and falsifier are recorded before execution, because a method chosen after seeing the data can be selected for the answer it produces. Revisions are counted rather than silent.

Thresholds are measured, not guessed. Duplicate detection uses trigram similarity at 0.30 — real restatements score 0.45–0.63, unrelated titles under 0.10, and an initial guess of 0.45 let a genuine duplicate through at 0.449.

What is not built

  • /oz start has never been executed. The spawn line is documented but background spawning is untested here. Try /oz task on one goal first.
  • The interactive flows are unrun. /oz refine, /oz design, /oz study and /oz goal are written and their tools are tested individually; the conversations are not.
  • Parity probes exist for documentation and code only. builds and infrastructure need a real check — a build, an applied migration — and a reference search would only pretend to answer them. screens is switched off.
  • No tests. The server is load-bearing and has none.
  • The markdown renderer that would regenerate a human-readable tracker from the database does not exist, so a migrated markdown tracker cannot be diffed against the database to prove nothing was lost.

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选