A plan could already have a tracking ticket, but the connection went one way and then stopped. The ticket's address was written into the plan's source file and never appeared on the plan people actually read, and finishing a plan did nothing to the ticket. Three changes close that loop.
The ticket question is now asked first, the ticket link is rendered onto the plan page, and completing a plan offers to close the ticket with a summary. Work landed on claude/create-ticket-prompt-order-579ee3 as e2e39c4 and 40e5817; the plan-agent plugin went from 7.2.0 to 7.4.0.
Affects: anyone generating a plan
At the end of plan generation, two questions arrive in a single prompt: "create a tracking issue?" and "what next — implement, review, exit?". The issue was already being created before the next-step choice was acted on, but it was asked second. The order in the prompt now matches the order things happen.
Where you see it: the last prompt of /plan-agent:implementation-plan.
Affects: anyone opening a plan page
A plan's source file can carry an issue: key — written either when the plan was generated from an existing ticket, or when a ticket was created for it. That key was kept in the source and dropped on the way to the HTML page, so a finished plan gave no hint which ticket belonged to it. The page now carries a link in its header, labelled Issue #512, plus a machine-readable plan-issue tag other tools can read.
Where you see it: any plan whose source has issue: <url>. Plans without one are unchanged, down to the byte.
Affects: anyone marking a plan done — and everyone watching the ticket
Both places that mark a plan completed — the build skill's completion gate and the finalize-plan skill — now act on that link. A summary is written first (plan filename, final status, criteria checked, and every completion-report note verbatim), and then one of two things happens:
Where you see it: /plan-agent:finalize-plan <plan>, /plan-agent:finalize-plan --all, or the completion gate at the end of /plan-agent:build.
The whole loop, from a plan being written to its ticket being closed. Three edges are new: the link reaching the rendered page, and the two ways completion reaches the tracker.
Look at the two exits from Final status: completed asks before closing, in progress never closes but still updates.
| Situation | Before | Now |
|---|---|---|
| Order of the two end-of-plan questions | Next step first, ticket second | Ticket first, next step second |
A plan whose source has issue: | Address kept in the source, invisible on the page | Header link plus a plan-issue tag |
A plan with no issue: | — | Renders exactly as before, byte for byte |
| Ticket address ending in a number | — | Link reads Issue #512 |
| Ticket address with no trailing number | — | Link reads Tracking issue |
| Plan marked completed | Ticket untouched | You are asked; on yes it closes with a summary |
| Plan downgraded to in progress | Ticket untouched | Never closed; summary posted as a comment |
| Sweeping many plans at once | — | One ticket question for the whole sweep |
| Tracker tool missing or not signed in | — | One line reported, plan still completes |
Plans already had a source key (prototype:) that becomes a page tag and a header link. The ticket link reuses that exact shape. Both are emitted only when the key exists, so plans without a ticket produce identical output — which is what keeps the existing check that re-renders all 84 committed plans green.
Rejecteda dedicated metadata block on the page, and a ticket badge on the plans gallery — both change output for plans that have no ticket.
Closing a ticket is visible to everyone watching it and changes its state. A comment only adds information, so it needs no question.
Rejectedclosing automatically on completion — the plan's author is not always the ticket's owner.
The comment is the honest signal: the ticket stays open, and it now says where the work stopped.
Rejectedsilence, which leaves the ticket looking untouched.
build and finalize-plan each own "mark this plan completed", and the codebase already flags that the two must be kept consistent by hand. Skills load independently, so a cross-reference would not be read. The test therefore asserts every clause against both files and names whichever one is missing it — landing the rule in only one place is the real failure mode.
The plan's status is already decided by the time the ticket is touched, so an unreachable tracker is reported in one line and the plan still completes.
Rejectedtreating an unreachable tracker as a completion failure.
7.2.0 → 7.3.0 for the rendered link, 7.3.0 → 7.4.0 for the completion behavior. New behavior is a minor bump under this repository's rules.
The canonical one is under scripts/; a bundled copy ships inside the plugin, and a check compares them byte for byte. Editing one and not the other fails with a "re-copy it" message rather than anything about the actual change.
The new test created its sandbox with the prefix plan-issue-link-, and the renderer writes project paths into the page — so the assertion "this page contains no plan-issue tag" was matching the directory name instead of the tag. Renaming the prefix fixed it. Any assertion of the form "output does not contain X" is worth checking against the scaffolding that produced the output.
The repository has a check that runs several skills headlessly and compares structural facts about what they wrote. It reported 4 of 5 matching; a full re-run reported 5 of 5, and a third run after the build skill was edited also reported 5 of 5. These runs involve a live model, so a single divergence is worth re-running before it is worth investigating.
Two contract assertions failed only because the phrases they searched for were split across lines in the skill file. The fix was to rewrap the sentences, not to loosen the test — a test that tolerates arbitrary wrapping stops asserting the phrase.
The closure behavior is instructions the model follows, and the test asserts those instructions exist in both skills — not that a real ticket changes state. A test against a throwaway repository would close that gap.
The GitHub path uses one command with a comment flag; GitLab needs a comment and then a close, and that pairing has not been run against a real GitLab remote.
Prototypes get a marker on the gallery card; tickets do not. Deliberately skipped — adding one changes the gallery output for every plan.
scripts/lib/plan-shell.mjs — emits the plan-issue tag and the header linkscripts/build-plan-html.mjs — reads the issue: key, derives the link labelkit/plugins/plan-agent/scripts/lib/plan-shell.mjs — bundled copykit/plugins/plan-agent/scripts/build-plan-html.mjs — bundled copyskills/implementation-plan/SKILL.md — ticket question asked first; notes that the key now rendersskills/build/SKILL.md — ticket update added to the completion gateskills/finalize-plan/SKILL.md — new ticket step covering both edit modes and the sweepskills/implementation-plan/guidelines/section-catalog.md — issue: documented as rendered, no longer listed as inerttests/plugins/test-plan-issue-link.mjs — new; 3 checks on the rendered link and its absencetests/plugins/test-plan-ticket-closure.sh — new; 8 checks, each asserted against both completion skillskit/plugins/plan-agent/README.md — describes the link and what completion does with itkit/plugins/plan-agent/CHANGELOG.md — 7.3.0 and 7.4.0 entries.claude-plugin/marketplace.json — version 7.4.0key: value lines at the top of the spec. issue: is one of those keys.plan-issue is the one added here.build and finalize-plan are skills.finalize-plan --all, which finalizes many plans in one run.