/review-ticket

name: review-ticket
description: Triage a ticket or ticket set before work starts, saving a review with the questions worth raising.
disable-model-invocation: true
type: flow
license: MIT
metadata:
  version: "1.8"

Review ticket

A pre-pickup triage glance: read a ticket — or a set of tickets forming one feature — usually before anyone has started it, and decide whether it can be picked up or something must be clarified first. The output briefs the developer on the feature and lists the questions worth asking whoever owns the requirements.

Input

• **Local ticket document(s)**: a single `.TICKET.md`, several, a ticket-set directory, or a

`.TICKET.md` whose `## Ticket set` section lists siblings.

• **One or more ticket URLs or bare ids/keys**: delegate — even for a single one — to a subagent

running [fetch-ticket](../fetch-ticket/SKILL.md) per its [delegate.md](../fetch-ticket/delegate.md), so the tickets land on disk without the fetch bloating this session's context, then review the local files. No subagents in the harness → run fetch-ticket inline.

Missing attachments (a non-empty warn list, or a ticket file marking one `not downloaded`) stop for one question: supply the files now (`/attach-to-ticket` when available) or review without them. An `/attach-to-ticket` run in answer resumes the review with the files it saved; each attachment still missing is named as unchecked material.

If the input is ambiguous or unrecognized, ask rather than guess.

**Set mode** applies to multiple tickets, a set directory, or a `.TICKET.md` listing a `## Ticket set`. For a lone member file whose intended scope isn't obvious from the request, ask whether to review the whole set or just that ticket.

Read the materials

Read the input ticket file(s), **visually inspecting the downloaded images and design frames** — they are part of the spec and often where the gaps hide.

**Widen only on demand.** When the input already tells the feature clearly — the journey, the why, what each ticket delivers — review it as-is: reading beyond the input is never a required step. Settle a specific doubt as cheaply as possible, and only to answer it:

• first, material already on disk: set siblings, a parent feature/epic, designs — a technical

ticket's journey often lives in its parent or a sibling;

• remotely, only for what is still missing: a design inspected through its tool's MCP, a related

ticket deep-dived from the ticket file's shallow related list (title, status, type), a missing parent fetched through the same fetch-ticket subagent (its family routing lands it flat in the set directory).

Unsure the extra context is worth it? Ask. Stop once the doubt is answered; never recurse the related-ticket graph — except to kill a candidate question (see the question bar). Context never widens scope: the review covers only the input tickets, never a parent's other children.

An earlier review

Look for a `.TICKET-REVIEW.md` of the same ticket or set, beside it or beside an earlier `-vN` fetch. Its shipped questions are the first candidates: settle each against the ticket text as fetched now (comments included) and its Challenge log, then run the normal bar. Never copy its verdict or walkthrough; the ticket files and the code win.

Compare against the codebase

Weigh the ticket against the current code at adaptive depth: shallow by default, deeper only to (a) ground the walkthrough in how the code behaves today and (b) settle whether a real blocker exists. This is not an exhaustive both-sides verification: go as deep as a specific doubt demands, no more.

The question bar: both gates, or stay silent

A question reaches the output only when it clears **both**:

1. **Decision-expensive**: the answer changes what this developer builds — it blocks starting, or would be costly to reverse because it shapes the implementation (architecture, data model, approach). Cheap, easily-changed details (a color, a label, wording, spacing) are dropped even when unspecified. A real gap whose fix lies wholly outside the input tickets' scope (another repo, another team) is a **handoff**, not a question: it ships as an action item with a paste-ready message to its owner, and starting never waits on it. 2. **Survives the challenge**: a challenger (next section) hunted for the answer across every checkable source and came back empty-handed, with a complete evidence trail.

**Cheap-settle first.** Before challenging, settle each candidate as far as material already read or trivially reachable allows — set siblings on disk, code already open, an obvious lead (a telling title in an already-fetched relative's related list, a parent's other children included, a code path an earlier check surfaced). What a check settles, settle silently: never ask what you can read. The exhaustive hunts — whole-repo sweeps, tracker keyword search, design-tool exploration — are the challenger's job alone: never duplicate them here, and pass any lead you didn't follow into the challenger prompt.

**Zero questions is a clean, common result**: the ticket is ready to pick up. Never pad to look thorough. Zero candidates → zero challengers.

The challenge

Before the first challenger, resolve every repo the feature spans, as named by the tickets and the project's governing docs, the other side of each integration included (a backend ticket's frontend, an API's clients). Any that can't be located: one batched ask for their paths; a repo the user skips is listed in the prompt as unavailable.

Each surviving candidate gets one challenger — a subagent or equivalent isolated context, fresh per question, spawned in parallel, strictly read-only — prompted from the template in [challenger-prompt.md](challenger-prompt.md). When the harness cannot isolate a context, run the same template procedure inline over the same sources and flag each surviving question's why-note "challenged same-context (weaker)".

Judge the verdicts