القائمة
Triage a ticket or ticket set before work starts — compare it against the codebase and save a review covering verdict, feature walkthrough, and only the high-cost questions worth raising.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Audit the current project's agent-memory and, block by block, relocate each entry into a user-controlled home (project doc/skill/rule or user-level skill/rule) or archive it — draining memory so nothing uncontrolled accumulates in the agent's context.
How to write texts meant to be published by humans for other humans.
Fresh-eyes review of a changeset by a fresh-context agent — catches regressions and correctness issues the authoring context reads past.
Check how much of a ticket is already implemented — split it into requirement blocks, judge each against the code, and save a human-readable TICKET-STATUS report in the planning dir.
Author or refine a skill for maximum token economy without losing intent. Use when creating any new skill or editing an existing `SKILL.md`.
Audit what auto-loads into an agent session's context window and suggest lean, reversible fixes to cut startup tokens.
استنادا إلى تصنيف SOC المهني
| name | review-ticket |
| description | Triage a ticket or ticket set before work starts — compare it against the codebase and save a review covering verdict, feature walkthrough, and only the high-cost questions worth raising. |
| disable-model-invocation | true |
| type | flow |
| license | MIT |
| metadata | {"author":"Francesco Borzì","version":"0.5"} |
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.
.TICKET.md, several, a ticket-set directory, or a
.TICKET.md whose ## Ticket set section lists siblings.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 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:
Unsure the extra context is worth it? Ask. Stop once the doubt is answered; never recurse the related-ticket graph. Context never widens scope: the review covers only the input tickets, never a parent's other children.
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.
A question reaches the output only when it clears both:
Zero questions is a clean, common result: the ticket is ready to pick up. Never pad to look thorough.
Verdict line first, so the answer lands at once, e.g.
2 questions to resolve before starting or Looks ready to pick up, no blockers.
Feature walkthrough, in the voice of a senior dev briefing a colleague ("we need to implement X, Y and Z, and there are a couple of questions we might want to ask the PO first"). A good structure could be layered, most important first, so the reader can stop at any depth:
log in → client area (**klantportaal**) → submit request → status updates.Introduce each core domain term in plain, memorable words at first use — a contrast or direction hook beats a bare definition.
Technical depth caps at "this screen calls endpoints X and Y to get its data": generally no need to go deep into architecture decisions. Single ticket: same layers, proportionally shorter.
Questions, when any cleared both gates: a numbered list, each item bracketed top and bottom
by a ~40-char rule of ━ so the eye jumps between them. Each item carries the question
(paste-ready, in a natural human voice, no AI tells, no dashes, citing the ambiguous part of the
ticket or the relevant code to stay concrete) and a short why-it-matters note to you for
deciding whether to forward it. When nothing cleared both gates, print only the verdict line.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
### 1 · <short label>
Question to ask, a sentence or two in a real person's voice.
Why it matters: the cost if we guess wrong.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The review is read by a human — raw in the terminal and later rendered as markdown, so format for
both: small blocks of a few sentences, each opened by a bold lead-in, blank lines between them,
~40-char ━ rules between major parts (nutshell + flow-line, journey, ticket mapping) — never
tables, nested lists, # headings, or a wall of text. In the saved file, embed the one or two
on-disk design frames that show the journey's main screens — a picture beats a paragraph.
User-facing texts in another language? Follow each mentioned page, area, or label with the name
the user sees, bold, in parentheses: "the client area (klantportaal)".
Print the review and always save it too:
<id>-<slug>.TICKET-REVIEW.md in the set directory, named after the feature/set,
so 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 (its local file when on disk, else its tracker URL), so a later session finds everything from the review file.
Close by pointing at /verify-understanding <review-file>; with no blockers, also
/refine-ticket <ticket-file> per ticket, in the set's suggested execution order.
.TICKET-REVIEW.md.