This was generated by AI during triage.
Problem: the pipeline is open at the end
/to-tickets publishes tracer-bullet tickets labeled ready-for-agent. /implement builds the work and its last step is "Commit your work to the current branch." Nothing after that is written — so completed tickets stay open on ready-for-agent forever after their work has shipped, and the frontier fills with already-done work.
/triage can't close them either: its state machine has five states (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix), and "the work this ticket described is now merged" is not a transition it knows. Its only close path is wontfix (already implemented / rejected) — that fires when triage discovers an existing implementation, not when the work an issue described gets done.
So spec → tickets → implement is a one-way pipeline with no exit for the tickets it creates.
Two possible fixes
A. One closing step in /implement (small): after "Commit your work to the current branch", add: close each completed ticket (as completed) with one comment carrying the verification pointer — the PR link, or the branch commit when no PR exists. Parent specs stay untouched; closing those remains the maintainer's call.
B. A done transition in /triage (larger): add a sixth state role for work-completed closures so a triage sweep can recognize and close already-shipped tickets. This touches the state machine and partially overlaps both wontfix (already implemented) and GitHub's native closed state.
I think A is the minimal change that closes the loop — implement is where "the work is done" is first known, so it's the natural place to act on it. I've drafted A on a branch (one 2-line addition to skills/engineering/implement/SKILL.md) and can open the PR if this direction sounds right — happy to take it toward B, or A+B, if you'd rather the state machine own the transition.
Problem: the pipeline is open at the end
/to-ticketspublishes tracer-bullet tickets labeledready-for-agent./implementbuilds the work and its last step is "Commit your work to the current branch." Nothing after that is written — so completed tickets stay open onready-for-agentforever after their work has shipped, and the frontier fills with already-done work./triagecan't close them either: its state machine has five states (needs-triage,needs-info,ready-for-agent,ready-for-human,wontfix), and "the work this ticket described is now merged" is not a transition it knows. Its only close path iswontfix(already implemented / rejected) — that fires when triage discovers an existing implementation, not when the work an issue described gets done.So
spec → tickets → implementis a one-way pipeline with no exit for the tickets it creates.Two possible fixes
A. One closing step in
/implement(small): after "Commit your work to the current branch", add: close each completed ticket (as completed) with one comment carrying the verification pointer — the PR link, or the branch commit when no PR exists. Parent specs stay untouched; closing those remains the maintainer's call.B. A
donetransition in/triage(larger): add a sixth state role for work-completed closures so a triage sweep can recognize and close already-shipped tickets. This touches the state machine and partially overlaps bothwontfix(already implemented) and GitHub's native closed state.I think A is the minimal change that closes the loop —
implementis where "the work is done" is first known, so it's the natural place to act on it. I've drafted A on a branch (one 2-line addition toskills/engineering/implement/SKILL.md) and can open the PR if this direction sounds right — happy to take it toward B, or A+B, if you'd rather the state machine own the transition.