--- name: check-ticket-implementation description: Check how much of a ticket is already implemented and save a per-requirement status report. disable-model-invocation: true type: flow license: MIT metadata: version: "1.3" --- # Check ticket implementation Judge how much of a ticket is already implemented and report it so the user sees at a glance what is done, what isn't, and what still needs attention. ## Gather Input is a ticket URL / bare id — run [fetch-ticket](../fetch-ticket/SKILL.md) on it (it resolves the tracker and planning dir and persists the `.TICKET.md`) — or a path to an already-fetched ticket file or its task dir. Ambiguous input: ask, don't guess. Run the fetch in a **subagent** when the runtime supports one, per fetch-ticket's [delegate.md](../fetch-ticket/delegate.md), so its tool traffic stays out of this session's context. Without subagent support, invoke fetch-ticket inline. The **ticket text is what gets annotated** — its `.REQUIREMENTS.md` (same dir and `-` base — a shared dir may hold siblings'; none: the ticket's latest across `-vN` versions) may be read as context for intent, never annotated in its place. The ticket text stays the contract: when the requirements record an Override that changes a block's meaning, the verdict follows the text and the note names the Override and its source. Inspect downloaded attachments and design frames when they bear on a requirement being judged. **Evidence base**: the current working tree, uncommitted changes included — unless the invocation names something else (a branch, PR, commit range); then judge against that, read without moving the working tree. ## Blocks Turn every requirement-bearing statement into a block: description, acceptance criteria, and comment statements that add or change requirements (attribute those, e.g. "from comment by X"). A later statement that changes an earlier one supersedes it: one block, quoting the latest text, with the superseded text and its source in the note. Drop metadata and related-ticket lists; a comment set aside as chatty goes to the `## Not judged` appendix — the full text stays in the `.TICKET.md`. - One block = one independently verifiable requirement, quoted **verbatim** under a short generated title, preserving ticket order. - **Split on mixed verdict**: if two halves of a candidate block could end with different statuses, they are two blocks. PARTIAL always means one requirement itself half-built, never a bundle of a done and a not-done thing. ## Judge Statuses: ✅ DONE · 🟡 PARTIAL · 🟥 NOT DONE · ⚪ NOT VERIFIABLE (can't be judged from the code — say why, e.g. a manual deploy step). - **The ticket text is the contract.** Tests, i18n, docs, and other project conventions affect the verdict only when the ticket demands them; a gap there is at most a remark in the note, never a downgrade. - Verify by **reading**: search and read the code paths relevant to each block. When reading alone can't settle a verdict, say so in the note instead of guessing. Anything beyond reading — executing code, driving the app or a browser — only with the user's ok. - Built but contradicting the text (a different rule, value or behavior) is 🟥 NOT DONE, the note opening with what was built instead; 🟡 is reserved for a requirement that is incomplete, never for one that is wrong. - Every block gets a 1–2 sentence note and 1–3 `file:line` evidence refs showing where it was checked; for 🟡/🟥 the note must state what's missing or remaining. ## Report Write `/-.TICKET-STATUS.md`, overwriting any previous run — it is a snapshot of now, and the header says when and against what. (No task dir and nothing to fetch? Follow the project's/user's planning-dir convention, defaulting to `.agents/plans/`; ask only if genuinely ambiguous.) Format for human eyes — verdicts up front, blocks fenced by `━` rules. Before writing the notes, actually invoke [explain-in-simple-language](../explain-in-simple-language/SKILL.md) and follow it — reciting its rules from memory does not count. Not installed: plain words, one idea per sentence, and nothing named only by a stand-in the reader hasn't seen. ```markdown # — implementation status > **Ticket** []() · **Checked** · **Against** @ (+ uncommitted) **4 ✅ · 2 🟡 · 1 🟥 · 1 ⚪** Needs attention: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### ✅ DONE — > — `path/to/file.ts:42` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` End the file with a `## Not judged` appendix, opened by a one-liner saying it is tracing only: one line per comment set aside, with the reason. ## Wrap up Print the tally line, the needs-attention titles, and the project-relative path of the report. Nothing more — what to do about the gaps is the user's call. ## Boundaries - **Read-only** on tracker and code: never comment on or transition the ticket, never modify source. The only file written is the `.TICKET-STATUS.md` (plus whatever fetch-ticket persists when delegated). - Never grill the user on requirement questions; uncertainty lands in the notes.