القائمة
Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
| name | to-issues |
| description | Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. |
| disable-model-invocation | true |
Break a plan into issues anyone can grab independently, cutting them as vertical slices (tracer bullets).
The issue tracker and triage label vocabulary should already have been handed to you — run /setup-skills if not.
Work from whatever's already in the conversation. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read the full body and comments.
If you haven't explored the codebase yet, do so to learn the current state of the code. Issue titles and descriptions should use the project's domain glossary and respect ADRs covering the area you're touching.
Look for chances to prefactor the code so the implementation lands more easily. "Make the change easy, then make the easy change."
Cut the plan into tracer bullet issues, following the Vertical slice rules. A wide refactor is the exception — slice it by expand–contract instead (see Wide refactors).
Present the proposed breakdown as a numbered list. For each slice, show:
Ask the user:
Iterate until the user signs off on the breakdown.
For each approved slice, publish a new issue using the Issue body template. These issues are AFK-ready, so publish them with the correct triage label unless told otherwise.
Publish in dependency order (blockers first) so you can cite real issue identifiers. Where the tracker supports it, link each slice to its parent as a native sub-issue and wire each blocker as a native blocking edge (mechanics in the issue-tracker doc); the ## Parent and ## Blocked by body sections are the fallback.
Do NOT close or modify any parent issue.
Each issue is a thin vertical slice cutting through ALL integration layers end to end — NOT a horizontal slice of a single layer.
A wide refactor is a single mechanical change — rename a column, retype a shared symbol — whose blast radius fans across the whole codebase, so one edit shatters thousands of call sites at once and no vertical slice can land green. Don't wrestle it into a tracer bullet; sequence it as expand–contract. First expand: add the new form alongside the old so nothing breaks. Then migrate the call sites in batches sized by blast radius (per package, per directory), each batch its own issue blocked by the expand, and CI stays green batch to batch because the old form still stands. Finally contract: delete the old form once no caller remains, in an issue blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify issue — green is promised only there.
A reference to the parent issue on the issue tracker (include only if the source was an existing issue; otherwise omit this section).
A concise description of this vertical slice. Describe the end-to-end behaviour, not a layer-by-layer implementation.
Avoid specific file paths or code snippets — they go stale fast. Exception: if the /prototype skill produced code that captures a decision more precisely than prose could (a state machine, reducer, schema, type shape), add a context pointer to where that prototype code lives rather than inlining it.
Or "None - can start immediately" when there are no blockers.
