Issue Tracker Link

Issue Tracker Link

Since 1.7.0. Your spec stays the source of truth — and your Jira board or GitHub Issues stay the window your team looks through. FeatherSpec links the two with one line, two offers and zero tracker knowledge of its own.

Solo developer? Answer the last wizard question with none and you will never read about tickets again. This page is for teams whose work is tracked somewhere.

What it does

You do	FeatherSpec does
Finish a spec with /sdd-specify	asks "Create a ticket for this spec?" — a yes creates the ticket from the spec's title, goals and acceptance criteria and writes **Ticket:** KAN-4 into the spec header
Move it with /sdd-lifecycle … active	proposes move → active/ + KAN-4 → In Progress? — one yes covers both
Start implementing via /sdd-plan	the start signal moves the spec and asks for the same transition
Finish with /sdd-lifecycle … done	proposes move → done/ + KAN-4 → Done? plus a one-line completion comment
Reactivate or deprecate	back to In Progress, or closed with a comment naming the successor

Every network write sits behind the Ask-first gate: the tool acts only after your yes. A tracker that is down, a missing login, a wrong project key — none of that stops the SDD flow. The spec is finished anyway, and the failure is recorded in its Open points as Ticket: pending — <reason> (or Ticket sync: failed — <reason> on a move) so you can pick it up later. A no leaves the spec untouched.

The whole link is one optional header line beneath **Plan:**:

**Status:** In Progress
**Plan:** [0001-split-tip.plan.md](../plans/0001-split-tip.plan.md)
**Ticket:** KAN-4

Set it by hand to link a spec to a ticket that already exists — /sdd-lifecycle picks it up on the next move. On GitHub the id is #42, and the agent may write it as a link.

Switch it on

Run /sdd-setup (or re-run it in an existing project). Its last question:

Where do tickets for this project live — GitHub, Jira, another tracker, or nowhere?

The answer becomes one line in the managed settings block of AGENTS.md:

IssueTracker: jira # none | github | jira | <other> — set by /sdd-setup

For Jira or any other tracker the wizard also asks for the project key (KAN, PROJ, …) and records it in .memory-bank/techContext.md. That is the entire configuration. No login, no token, no URL — and nothing is verified live during setup.

Projects that update from an older version receive the line through /sdd-featherspec-update as a slot edit you confirm individually; it arrives as none.

Connect your tracker

FeatherSpec ships no tracker API knowledge. The agent uses whatever your tool already has, so a changed Jira endpoint or a new GitHub API version is never a FeatherSpec update. Pick your row:

Tracker	Claude Code	GitHub Copilot (VS Code)
GitHub Issues	gh auth login — the agent uses the gh CLI. Or add the GitHub MCP server if you prefer.	Nothing to do: the GitHub MCP server is built into agent mode.
Jira Cloud	claude mcp add --transport http --scope user atlassian https://mcp.atlassian.com/v1/mcp, then /mcp → atlassian → Authenticate.	Install the Atlassian MCP server from the Extensions view (one click), sign in when prompted.
Linear, Azure DevOps, YouTrack, …	Add the tracker's own MCP server (claude mcp add …).	Add it from the Extensions view or mcp.json.

Use --scope user in Claude Code so every project on your machine sees the server. The official Atlassian server authenticates with OAuth and respects the permissions your Jira account already has — the agent cannot do anything you could not do yourself.

A quick check before the first spec: ask your agent "show me the open issues in KAN". The answer must come from the tracker's tools, not from memory.

What a move looks like

From a real Jira run (German locale, so the status names are Zu erledigen, In Bearbeitung, Erledigt — the agent resolves transition ids at runtime, whatever they are called):

Agent: Move → done/ + KAN-5 → Done? One yes covers all of it: the spec moves, the plan is archived, the ticket transitions to Erledigt with the comment "Implemented — spec 0002 moved to done."

You: yes

GitHub Issues have no status field. There, In Progress is a one-line comment on the issue, Done closes it, reactivation reopens it — the agent never invents labels.

Teams that want every change synced

The two offers above cover the explicit lifecycle moves. If your team wants the ticket updated on every status change — including edits to the **Status:** line outside /sdd-lifecycle — add one bullet to Style & Output Preferences in AGENTS.md:

- **Ticket sync: on every spec status change, transition the linked ticket** — not only on
  lifecycle moves.

That bullet costs only the projects that want it. Everyone else pays exactly one line of context.

Limits, on purpose

• No ticket is created without a yes, no transition runs without a yes.
• Plans are never mirrored into the tracker — the plan is the developer's document.
• A missing **Ticket:** line means "no ticket": nothing is looked up, nothing is guessed.
• Ticket bodies are written once at creation; later spec edits do not rewrite the ticket.
• FeatherSpec does not read tickets into specs. The spec is written from the interview, the ticket from the spec — never the other way round.

See also

• Configuration → IssueTracker
• Commands → /sdd-specify and /sdd-lifecycle
• Specs and Plans for the header line
• Updating & Versioning for how the setting reaches older projects