[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74PHPPCREHGAWNKJEA28WFP":3,"skill-same:01M74PHPPCREHGAWNKJEA28WFP":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":33,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":6,"updatedAt":36,"install":37,"resources":49},"01M74PHPPCREHGAWNKJEA28WFP","review-ticket",null,"Triage a ticket or ticket set before work starts, saving a review with the questions worth raising.","eai-org\u002Fagent-toolkit","eai-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F301886321?v=4","01M74PFC3HF57T58MQ14P212BQ","Engineering in the age of AI","01M74PFC46MSKTT9SW5Q437FSD",85,"MIT","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Freview-ticket\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: review-ticket\ndescription: Triage a ticket or ticket set before work starts, saving a review with the questions worth raising.\ndisable-model-invocation: true\ntype: flow\nlicense: MIT\nmetadata:\n  version: \"1.8\"\n---\n\n# Review ticket\n\nA 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\n## Input\n\n- **Local ticket document(s)**: a single `.TICKET.md`, several, a ticket-set directory, or a\n  `.TICKET.md` whose `## Ticket set` section lists siblings.\n- **One or more ticket URLs or bare ids\u002Fkeys**: delegate — even for a single one — to a subagent\n  running [fetch-ticket](..\u002Ffetch-ticket\u002FSKILL.md) per its\n  [delegate.md](..\u002Ffetch-ticket\u002Fdelegate.md), so the tickets land on disk without the fetch\n  bloating this session's context, then review the local files. No subagents in the harness → run\n  fetch-ticket inline.\n\nMissing attachments (a non-empty warn list, or a ticket file marking one `not downloaded`) stop for\none question: supply the files now (`\u002Fattach-to-ticket` when available) or review without them.\nAn `\u002Fattach-to-ticket` run in answer resumes the review with the files it saved; each attachment\nstill missing is named as unchecked material.\n\nIf the input is ambiguous or unrecognized, ask rather than guess.\n\n**Set 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.\n\n## Read the materials\n\nRead 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.\n\n**Widen 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:\n\n- first, material already on disk: set siblings, a parent feature\u002Fepic, designs — a technical\n  ticket's journey often lives in its parent or a sibling;\n- remotely, only for what is still missing: a design inspected through its tool's MCP, a related\n  ticket deep-dived from the ticket file's shallow related list (title, status, type), a missing\n  parent fetched through the same fetch-ticket subagent (its family routing lands it flat in the\n  set directory).\n\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.\n\n## An earlier review\n\nLook for a `.TICKET-REVIEW.md` of the same ticket or set, beside it or beside an earlier `-vN`\nfetch. Its shipped questions are the first candidates: settle each against the ticket text as\nfetched now (comments included) and its Challenge log, then run the normal bar. Never copy its\nverdict or walkthrough; the ticket files and the code win.\n\n## Compare against the codebase\n\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.\n\n## The question bar: both gates, or stay silent\n\nA question reaches the output only when it clears **both**:\n\n1. **Decision-expensive**: the answer changes what this developer builds — it blocks starting,\n   or would be costly to reverse because it shapes the implementation (architecture, data model,\n   approach). Cheap, easily-changed details (a color, a label, wording, spacing) are dropped even\n   when unspecified. A real gap whose fix lies wholly outside the input tickets' scope (another\n   repo, another team) is a **handoff**, not a question: it ships as an action item with a\n   paste-ready message to its owner, and starting never waits on it.\n2. **Survives the challenge**: a challenger (next section) hunted for the answer across every\n   checkable source and came back empty-handed, with a complete evidence trail.\n\n**Cheap-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.\n\n**Zero questions is a clean, common result**: the ticket is ready to pick up. Never pad to look\nthorough. Zero candidates → zero challengers.\n\n## The challenge\n\nBefore the first challenger, resolve every repo the feature spans, as named by the tickets and\nthe project's governing docs, the other side of each integration included (a backend ticket's\nfrontend, an API's clients). Any that can't be located: one batched ask for their paths; a repo\nthe user skips is listed in the prompt as unavailable.\n\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\n[challenger-prompt.md](challenger-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)\".\n\nJudge the verdicts asymmetrically, in both directions:\n\n- **KILLED \u002F RESHAPED — verify before accepting.** Accept only on a verifiable citation (file\n  path + lines + verbatim quote, ticket id + quoted text, design frame id): open the load-bearing\n  citation yourself and confirm it exists as quoted **and answers the question as asked** —\n  related evidence is not an answer. Either check fails → reject the verdict, the question stays.\n  A derivation kill rests on multiple quotes composing an inference: verify each quote and that\n  the conclusion follows.\n  RESHAPED is a partial kill: same citation bar for the answered part, and the trail must\n  explicitly cover the remainder; the narrowed question is not re-challenged.\n- **OPEN — accept only with a complete trail**: every source class probed, with what it said. On\n  an incomplete trail (a dead or errored challenger counts as one): unless the invocation preset\n  a re-challenge budget, ask the user — one batched ask covering all weak trails — whether to\n  spend a re-challenge aimed only at the unchecked sources. Still incomplete after that → keep\n  the question, naming the unchecked sources in its why-note; an unavailable source (rate-limited\n  tool, missing repo) is recorded as unchecked, never exhausted. A question is dropped only by a\n  verified kill, never by challenger failure.\n\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.\n\n## Output\n\nBefore writing the walkthrough and the why-it-matters notes, actually invoke\n[explain-in-simple-language](..\u002Fexplain-in-simple-language\u002FSKILL.md) and follow it — reciting its\nrules from memory does not count. Not installed: plain words, one idea per sentence, and nothing\nnamed only by a stand-in the reader hasn't seen.\n\n1. **Verdict line** first, so the answer lands at once, e.g.\n   `2 questions to resolve before starting` or `Looks ready to pick up, no blockers.`\n   Handoffs never count as blockers here.\n2. **Feature walkthrough**, in the voice of a senior dev briefing a colleague (\"we need to\n   implement X, Y and Z, and there are a couple of questions we might want to ask the PO first\").\n   A good structure could be layered, most important first, so the reader can stop at any depth:\n   - **Nutshell** — the whole feature in 2–3 plain sentences.\n   - **Flow-line** — the journey's shape in one line:\n     `log in → client area (**klantportaal**) → submit request → status updates`.\n   - **Journey** — one concrete user doing real actions: who they are, what they see and do, why\n     the feature exists — never abstract capability-speak (\"users are able to…\"). Grounded in the\n     real current behavior you saw in the code; where the contrast clarifies, a bold-led\n     **Today** \u002F **After** pair. Must fit one terminal screen (~25 lines).\n   - **Ticket mapping** (set mode) — how each input ticket maps into the journey, one block per\n     ticket, led by its linked ticket id and short title.\n\n   Introduce each core domain term in plain, memorable words at first use — a contrast or\n   direction hook beats a bare definition.\n\n   Technical depth caps at \"this screen calls endpoints X and Y to get its data\": generally no\n   need to go deep into architecture decisions. Single ticket: same layers, proportionally shorter.\n3. **Questions**, when any survived the question bar: a numbered list, each item bracketed top\n   and bottom by a ~40-char rule of `━` so the eye jumps between them. Each item carries the\n   **question** (paste-ready, citing the ambiguous part of the ticket or the relevant code to\n   stay concrete) and a short **why-it-matters note to you** for deciding whether to forward it.\n   A handoff uses the same block format, `### Handoff · \u003Cshort label>` in place of the number.\n   Actually invoke [use-conversational-language](..\u002Fuse-conversational-language\u002FSKILL.md) and\n   follow it before writing the questions or handoff messages — reciting its rules from memory\n   does not count; runs with neither skip it. Not installed: write plain prose instead, no dashes\n   and no AI tells. Nothing survived: this part holds the handoffs only, or is left out.\n\n```\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n### 1 · \u003Cshort 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━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\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 `### \u003Cn> · \u003Clabel>` 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**)\".\n\n## Persist\n\nPrint the review and always save it too:\n\n- **Set mode**: `\u003Cdir-name>.TICKET-REVIEW.md` in the set directory, named after it (the\n  directory carries the parent id when there is one), so it sorts next to the `.TICKET.md` files.\n- **Single ticket**: `\u003Cid>-\u003Cslug>.TICKET-REVIEW.md` next to its `.TICKET.md`, under the ticket\n  file's current base (a `-v2` ticket gets a `-v2` review).\n\nAn earlier review of the same base is replaced, after saying so.\n\nThe 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.\n\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.\n\nClose by handing off each next phase as its own fenced block under the label quoted below, holding\none copy-pasteable launch command in the syntax of the agent tool in use (`claude` is only the\nexample), session named `\u003Cphase>-\u003Cslug>`.\nA block only when its skill is available; the refine blocks only with no blockers, one per ticket in\nthe set's suggested execution order, each label naming its ticket:\n\n\"Verify your understanding of the set first:\"\n\n```\nclaude --name verify-\u003Cslug> \"\u002Fverify-understanding \u003Creview-file>\"\n```\n\n\"Refine \u003Cticket>:\" (the first starting \"or\" when the verify block precedes it)\n\n```\nclaude --name refine-\u003Cslug> \"\u002Frefine-ticket \u003Cticket-file>\"\n```\n\nThen the alternative: one line offering the tool's clear command (`\u002Fclear` is only the example),\nthen the same labelled blocks with the bare slash commands. When Today already seems to deliver the\nAfter, also suggest `\u002Fcheck-ticket-implementation \u003Cticket-file>`, only when that skill is available.\n\n## Boundaries\n\n- **Read-only on tracker and code.** Never modify the tracker (comments, transitions, edits) or any\n  source file. The only files written are fetch-ticket's outputs, the `.TICKET-REVIEW.md`, and\n  what an `\u002Fattach-to-ticket` run in answer to the attachments question writes (assets beside the\n  ticket, the ticket's attachment entries, the appended Context line of an existing same-ticket\n  REQUIREMENTS).\n- **Non-interactive on requirements.** The questions are the output: never grill the user to\n  resolve them. Ask the user only operational things (an ambiguous input, a fetch that needs\n  input, the set-scope call, whether extra context is worth fetching, missing repo paths, missing\n  attachments, whether to spend a re-challenge), never requirement decisions.\n","# Review ticket\n\nA 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\n## Input\n\n- **Local ticket document(s)**: a single `.TICKET.md`, several, a ticket-set directory, or a\n  `.TICKET.md` whose `## Ticket set` section lists siblings.\n- **One or more ticket URLs or bare ids\u002Fkeys**: delegate — even for a single one — to a subagent\n  running [fetch-ticket](..\u002Ffetch-ticket\u002FSKILL.md) per its\n  [delegate.md](..\u002Ffetch-ticket\u002Fdelegate.md), so the tickets land on disk without the fetch\n  bloating this session's context, then review the local files. No subagents in the harness → run\n  fetch-ticket inline.\n\nMissing attachments (a non-empty warn list, or a ticket file marking one `not downloaded`) stop for\none question: supply the files now (`\u002Fattach-to-ticket` when available) or review without them.\nAn `\u002Fattach-to-ticket` run in answer resumes the review with the files it saved; each attachment\nstill missing is named as unchecked material.\n\nIf the input is ambiguous or unrecognized, ask rather than guess.\n\n**Set 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.\n\n## Read the materials\n\nRead 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.\n\n**Widen 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:\n\n- first, material already on disk: set siblings, a parent feature\u002Fepic, designs — a technical\n  ticket's journey often lives in its parent or a sibling;\n- remotely, only for what is still missing: a design inspected through its tool's MCP, a related\n  ticket deep-dived from the ticket file's shallow related list (title, status, type), a missing\n  parent fetched through the same fetch-ticket subagent (its family routing lands it flat in the\n  set directory).\n\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.\n\n## An earlier review\n\nLook for a `.TICKET-REVIEW.md` of the same ticket or set, beside it or beside an earlier `-vN`\nfetch. Its shipped questions are the first candidates: settle each against the ticket text as\nfetched now (comments included) and its Challenge log, then run the normal bar. Never copy its\nverdict or walkthrough; the ticket files and the code win.\n\n## Compare against the codebase\n\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.\n\n## The question bar: both gates, or stay silent\n\nA question reaches the output only when it clears **both**:\n\n1. **Decision-expensive**: the answer changes what this developer builds — it blocks starting,\n   or would be costly to reverse because it shapes the implementation (architecture, data model,\n   approach). Cheap, easily-changed details (a color, a label, wording, spacing) are dropped even\n   when unspecified. A real gap whose fix lies wholly outside the input tickets' scope (another\n   repo, another team) is a **handoff**, not a question: it ships as an action item with a\n   paste-ready message to its owner, and starting never waits on it.\n2. **Survives the challenge**: a challenger (next section) hunted for the answer across every\n   checkable source and came back empty-handed, with a complete evidence trail.\n\n**Cheap-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.\n\n**Zero questions is a clean, common result**: the ticket is ready to pick up. Never pad to look\nthorough. Zero candidates → zero challengers.\n\n## The challenge\n\nBefore the first challenger, resolve every repo the feature spans, as named by the tickets and\nthe project's governing docs, the other side of each integration included (a backend ticket's\nfrontend, an API's clients). Any that can't be located: one batched ask for their paths; a repo\nthe user skips is listed in the prompt as unavailable.\n\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\n[challenger-prompt.md](challenger-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)\".\n\nJudge the verdicts asymmetrically, in both directions:\n\n- **KILLED \u002F RESHAPED — verify before accepting.** Accept only on a verifiable citation (file\n  path + lines + verbatim quote, ticket id + quoted text, design frame id): open the load-bearing\n  citation yourself and confirm it exists as quoted **and answers the question as asked** —\n  related evidence is not an answer. Either check fails → reject the verdict, the question stays.\n  A derivation kill rests on multiple quotes composing an inference: verify each quote and that\n  the conclusion follows.\n  RESHAPED is a partial kill: same citation bar for the answered part, and the trail must\n  explicitly cover the remainder; the narrowed question is not re-challenged.\n- **OPEN — accept only with a complete trail**: every source class probed, with what it said. On\n  an incomplete trail (a dead or errored challenger counts as one): unless the invocation preset\n  a re-challenge budget, ask the user — one batched ask covering all weak trails — whether to\n  spend a re-challenge aimed only at the unchecked sources. Still incomplete after that → keep\n  the question, naming the unchecked sources in its why-note; an unavailable source (rate-limited\n  tool, missing repo) is recorded as unchecked, never exhausted. A question is dropped only by a\n  verified kill, never by challenger failure.\n\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.\n\n## Output\n\nBefore writing the walkthrough and the why-it-matters notes, actually invoke\n[explain-in-simple-language](..\u002Fexplain-in-simple-language\u002FSKILL.md) and follow it — reciting its\nrules from memory does not count. Not installed: plain words, one idea per sentence, and nothing\nnamed only by a stand-in the reader hasn't seen.\n\n1. **Verdict line** first, so the answer lands at once, e.g.\n   `2 questions to resolve before starting` or `Looks ready to pick up, no blockers.`\n   Handoffs never count as blockers here.\n2. **Feature walkthrough**, in the voice of a senior dev briefing a colleague (\"we need to\n   implement X, Y and Z, and there are a couple of questions we might want to ask the PO first\").\n   A good structure could be layered, most important first, so the reader can stop at any depth:\n   - **Nutshell** — the whole feature in 2–3 plain sentences.\n   - **Flow-line** — the journey's shape in one line:\n     `log in → client area (**klantportaal**) → submit request → status updates`.\n   - **Journey** — one concrete user doing real actions: who they are, what they see and do, why\n     the feature exists — never abstract capability-speak (\"users are able to…\"). Grounded in the\n     real current behavior you saw in the code; where the contrast clarifies, a bold-led\n     **Today** \u002F **After** pair. Must fit one terminal screen (~25 lines).\n   - **Ticket mapping** (set mode) — how each input ticket maps into the journey, one block per\n     ticket, led by its linked ticket id and short title.\n\n   Introduce each core domain term in plain, memorable words at first use — a contrast or\n   direction hook beats a bare definition.\n\n   Technical depth caps at \"this screen calls endpoints X and Y to get its data\": generally no\n   need to go deep into architecture decisions. Single ticket: same layers, proportionally shorter.\n3. **Questions**, when any survived the question bar: a numbered list, each item bracketed top\n   and bottom by a ~40-char rule of `━` so the eye jumps between them. Each item carries the\n   **question** (paste-ready, citing the ambiguous part of the ticket or the relevant code to\n   stay concrete) and a short **why-it-matters note to you** for deciding whether to forward it.\n   A handoff uses the same block format, `### Handoff · \u003Cshort label>` in place of the number.\n   Actually invoke [use-conversational-language](..\u002Fuse-conversational-language\u002FSKILL.md) and\n   follow it before writing the questions or handoff messages — reciting its rules from memory\n   does not count; runs with neither skip it. Not installed: write plain prose instead, no dashes\n   and no AI tells. Nothing survived: this part holds the handoffs only, or is left out.\n\n```\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n### 1 · \u003Cshort 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━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\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 `### \u003Cn> · \u003Clabel>` 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**)\".\n\n## Persist\n\nPrint the review and always save it too:\n\n- **Set mode**: `\u003Cdir-name>.TICKET-REVIEW.md` in the set directory, named after it (the\n  directory carries the parent id when there is one), so it sorts next to the `.TICKET.md` files.\n- **Single ticket**: `\u003Cid>-\u003Cslug>.TICKET-REVIEW.md` next to its `.TICKET.md`, under the ticket\n  file's current base (a `-v2` ticket gets a `-v2` review).\n\nAn earlier review of the same base is replaced, after saying so.\n\nThe 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.\n\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.\n\nClose by handing off each next phase as its own fenced block under the label quoted below, holding\none copy-pasteable launch command in the syntax of the agent tool in use (`claude` is only the\nexample), session named `\u003Cphase>-\u003Cslug>`.\nA block only when its skill is available; the refine blocks only with no blockers, one per ticket in\nthe set's suggested execution order, each label naming its ticket:\n\n\"Verify your understanding of the set first:\"\n\n```\nclaude --name verify-\u003Cslug> \"\u002Fverify-understanding \u003Creview-file>\"\n```\n\n\"Refine \u003Cticket>:\" (the first starting \"or\" when the verify block precedes it)\n\n```\nclaude --name refine-\u003Cslug> \"\u002Frefine-ticket \u003Cticket-file>\"\n```\n\nThen the alternative: one line offering the tool's clear command (`\u002Fclear` is only the example),\nthen the same labelled blocks with the bare slash commands. When Today already seems to deliver the\nAfter, also suggest `\u002Fcheck-ticket-implementation \u003Cticket-file>`, only when that skill is available.\n\n## Boundaries\n\n- **Read-only on tracker and code.** Never modify the tracker (comments, transitions, edits) or any\n  source file. The only files written are fetch-ticket's outputs, the `.TICKET-REVIEW.md`, and\n  what an `\u002Fattach-to-ticket` run in answer to the attachments question writes (assets beside the\n  ticket, the ticket's attachment entries, the appended Context line of an existing same-ticket\n  REQUIREMENTS).\n- **Non-interactive on requirements.** The questions are the output: never grill the user to\n  resolve them. Ask the user only operational things (an ambiguous input, a fetch that needs\n  input, the set-scope call, whether extra context is worth fetching, missing repo paths, missing\n  attachments, whether to spend a re-challenge), never requirement decisions.\n",{"name":5,"type":24,"license":15,"metadata":25,"description":7,"disable-model-invocation":27},"flow",{"version":26},"1.8",true,"main","12db59437c9d48b9bd62b18888e9974b17adafaf","skills\u002Freview-ticket",19,"https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit","https:\u002F\u002Feai-org.github.io\u002Fagent-toolkit-docs","https:\u002F\u002Fgithub.com\u002Feai-org","https:\u002F\u002Fmedium.com\u002Fengineering-in-the-age-of-ai","2026-11-14 22:36:21",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":27},[39,42,45],{"tool":40,"command":41},"npx","npx skills add eai-org\u002Fagent-toolkit --skill review-ticket",{"tool":43,"command":44},"bunx","bunx skills add eai-org\u002Fagent-toolkit --skill review-ticket",{"tool":46,"command":47},"pnpm","pnpm dlx skills add eai-org\u002Fagent-toolkit --skill review-ticket","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Freview-ticket\u002FSKILL.md",[50],{"path":51,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":54,"sourceHtmlUrl":55},"challenger-prompt.md","REFERENCE","参考文档",3090,"https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Freview-ticket\u002Fchallenger-prompt.md",[57,63,70,77,84,91],{"skillNo":58,"name":59,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M74PKAVPTTY5PSSAWHCRVY9T","no-frontmatter","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Fno-frontmatter\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M74PK8J99W7V3669Y4JG2JKV","other-name","Fixture skill whose name differs from its folder.","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Fname-mismatch\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M74PK6T9DHVRCNHTEV2ZA4Y3","md-off","A fixture skill whose folder turns the line length off below a root that sets 99.","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Fmd-off\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M74PK4H4N3D290V4C08M4DGY","long-line","Fixture skill with one prose line of 100 characters, over the fixtures' limit of 99.","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Flong-line\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M74PK2DJ2MCR5KFPMYVQWNJG","flag-without-flow","Fixture skill with the flag and no type.","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Fflag-without-flow\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M74PK03XGEBQ986FDAE46WCM","double-backtick","A fixture skill with double-backtick code spans holding a link template and an overrun.","https:\u002F\u002Fgithub.com\u002Feai-org\u002Fagent-toolkit\u002Fblob\u002Fmain\u002Ftest\u002Fcompact-skill-creator\u002Ffixtures\u002Fdouble-backtick\u002FSKILL.md",[],[]]