A pre-pickup triage glance: read a ticket — or a set of tickets forming one feature — usually\nbefore anyone has started it, and decide whether it can be picked up or something must be\nclarified first. The output briefs the developer on the feature and lists the questions worth\nasking whoever owns the requirements.
\n.TICKET.md, several, a ticket-set directory, or a\n.TICKET.md whose ## Ticket set section lists siblings.If the input is ambiguous or unrecognized, ask rather than guess.
\nSet mode applies to multiple tickets, a set directory, or a .TICKET.md listing a\n## Ticket set. For a lone member file whose intended scope isn't obvious from the request, ask\nwhether to review the whole set or just that ticket.
Read the input ticket file(s), visually inspecting the downloaded images and design frames —\nthey are part of the spec and often where the gaps hide.
\nWiden only on demand. When the input already tells the feature clearly — the journey, the\nwhy, what each ticket delivers — review it as-is: reading beyond the input is never a required\nstep. Settle a specific doubt as cheaply as possible, and only to answer it:
\nUnsure the extra context is worth it? Ask. Stop once the doubt is answered; never recurse the\nrelated-ticket graph — except to kill a candidate question (see the question bar). Context never\nwidens scope: the review covers only the input tickets, never a parent's other children.
\nWeigh the ticket against the current code at adaptive depth: shallow by default, deeper only to\n(a) ground the walkthrough in how the code behaves today and (b) settle whether a real blocker\nexists. This is not an exhaustive both-sides verification: go as deep as a specific doubt demands,\nno more.
\nA question reaches the output only when it clears both:
\nCheap-settle first. Before challenging, settle each candidate as far as material already read\nor trivially reachable allows — set siblings on disk, code already open, an obvious lead (a\ntelling title in an already-fetched relative's related list, a parent's other children included, a\ncode path an earlier check surfaced). What a check settles, settle silently: never ask what you\ncan read. The exhaustive hunts — whole-repo sweeps, tracker keyword search, design-tool\nexploration — are the challenger's job alone: never duplicate them here, and pass any lead you\ndidn't follow into the challenger prompt.
\nZero questions is a clean, common result: the ticket is ready to pick up. Never pad to look\nthorough. Zero candidates → zero challengers.
\nEach surviving candidate gets one challenger — a subagent or equivalent isolated context, fresh\nper question, spawned in parallel, strictly read-only — prompted from the template in\nchallenger-prompt.md. When the harness cannot isolate a context, run the\nsame template procedure inline over the same sources and flag each surviving question's why-note\n\"challenged same-context (weaker)\".
\nJudge the verdicts asymmetrically, in both directions:
\nFold the verdicts in: KILLED → settled silently, the answer surfacing as a walkthrough fact when\nit changes what the developer must know; RESHAPED → the question narrows; OPEN → the question\nships, its trail feeding the why-note (exhausted and unchecked sources). No OPEN or narrowed\nquestion ships before the session has rerun the Derive moves (challenger prompt, step 6) itself\nover the returned trail — a challenger can return every fact yet miss the inference. A derived\nanswer is a kill, held to the same citation bar; when enacting it lies outside the input tickets'\nscope, the question converts to a handoff.
\nVerdict line first, so the answer lands at once, e.g.\n2 questions to resolve before starting or Looks ready to pick up, no blockers.\nHandoffs never count as blockers here.
Feature walkthrough, in the voice of a senior dev briefing a colleague (\"we need to\nimplement X, Y and Z, and there are a couple of questions we might want to ask the PO first\").\nA good structure could be layered, most important first, so the reader can stop at any depth:
\nlog in → client area (**klantportaal**) → submit request → status updates.Introduce each core domain term in plain, memorable words at first use — a contrast or\ndirection hook beats a bare definition.
\nTechnical depth caps at \"this screen calls endpoints X and Y to get its data\": generally no\nneed to go deep into architecture decisions. Single ticket: same layers, proportionally shorter.
\nQuestions, when any survived the question bar: a numbered list, each item bracketed top\nand bottom by a ~40-char rule of ━ so the eye jumps between them. Each item carries the\nquestion (paste-ready, citing the ambiguous part of the ticket or the relevant code to\nstay concrete) and a short why-it-matters note to you for deciding whether to forward it.\nA handoff uses the same block format, ### Handoff · <short label> in place of the number.\nActually invoke use-conversational-language and\nfollow it before writing the questions or handoff messages — reciting its rules from memory\ndoes not count; runs with neither skip it. When nothing survived, print only the verdict line\nplus any handoffs.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n### 1 · <short label>\n\nQuestion to ask, a sentence or two in a real person's voice.\n\nWhy it matters: the cost if we guess wrong.\n\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nThe review is read by a human — raw in the terminal and later rendered as markdown, so format for\nboth: small blocks of a few sentences, each opened by a bold lead-in, blank lines between them,\n~40-char ━ rules between major parts (nutshell + flow-line, journey, ticket mapping) — never\ntables, nested lists, or a wall of text; no # headings apart from the ### <n> · <label> line\nopening each question item. In the saved file, embed the one or two on-disk design frames that\nshow the journey's main screens — a picture beats a paragraph.\nUser-facing texts in another language? Follow each mentioned page, area, or label with the name\nthe user sees, bold, in parentheses: \"the client area (klantportaal)\".
Print the review and always save it too:
\n<id>-<slug>.TICKET-REVIEW.md in the set directory, named after the feature/set,\nso it sorts next to the .TICKET.md files.<id>-<slug>.TICKET-REVIEW.md next to its .TICKET.md.The file must stand alone: carry relative links to each reviewed ticket file and to the parent\n(its local file when on disk, else its tracker URL), so a later session finds everything from the\nreview file.
\nEnd the saved file — never the printed review — with a ## Challenge log appendix, opened by a\none-liner saying it's tracing only and safe to ignore: each killed question (a reshape's answered\npart included) with the answer that settled it and its citation, and each cheap detail the\nquestion bar dropped, with the default assumed.
Close by pointing at /verify-understanding <review-file>; with no blockers, also\n/refine-ticket <ticket-file> per ticket, in the set's suggested execution order.
.TICKET-REVIEW.md.