Feature spec: requirements and a phased delivery plan

Start here when a feature is still one sentence in a ticket. Discovery & Spec turns it into requirements someone can check and a plan someone can schedule, before any application code is written.

Which agents run

1. Prior art. The Researcher surveys the code, libraries and references that bear on the feature. For an invoice export, that means where invoices are queried today and which serializers the service already uses.
2. Requirements. The Product Analyst writes requirements with acceptance criteria and scope boundaries.
3. Delivery plan. The Project Planner phases the work, with dependencies, milestones and effort estimates.

Each step reads what the earlier ones wrote.

What you get

• A proposed ADR. The agreed requirements are saved under Plan → ADRs as proposed, for a person to accept or reject.
• Plan board items. The Delivery plan step's list items become board entries, each linked to the session that proposed it.
• A spec in the repository. Every session on a project with a repository ends with a code pass, so the task asks for the spec in docs/specs/. That change gets the AI findings review, your test command and a human approval like any other, so the spec is discussed in a pull request where the team already comments.

Give the agents the facts they can't infer from code: who the users are, expected volumes, and what is explicitly out of scope.

Let agents read tickets, not write them

If your tracker is connected as a remote MCP server named "Tracker" (ID tracker), these policy rules keep its write tools away from every session while its read tools stay available:

[
  { "id": "tracker-no-create", "action": "mcp.invoke", "resource": "tracker/create_*", "decision": "deny" },
  { "id": "tracker-no-update", "action": "mcp.invoke", "resource": "tracker/update_*", "decision": "deny" }
]

mcp.invoke rules take allow or deny, never ask, and a denied tool is never offered to the agents. Tool names depend on the server you connect, so match the patterns to its real tool names. Try the rules in log-only mode first to see what they would block.

What comes next

Accept or reject the ADR, triage the board items, then build the first phase with the full-stack feature template or a smaller Plan, Build, Review & Test session per phase.