메뉴
Audit an issue tree (issue + epic + siblings) for continued relevance — verify its claims against HEAD, then recommend keep, rescope, or close, with drafted comments the user can apply.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Abstract a feature, user story, or flow into the capability primitives it rests on, graded against the current codebase, ending in an in-repo design doc with a build-order graph. Use when the user wants to decompose a feature into capabilities, check what a feature needs against what the codebase already provides, or settle build order before cutting issues.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
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.
| name | audit-issue |
| description | Audit an issue tree (issue + epic + siblings) for continued relevance — verify its claims against HEAD, then recommend keep, rescope, or close, with drafted comments the user can apply. |
| disable-model-invocation | true |
Assess whether an issue — and the tree around it, when it has one (parent epic, siblings); a lone issue is a tree of one — is still relevant, and end in recommendations the user can act on. The user must understand the issues before being asked to judge them — the sequencing below is deliberate: product focus captured as context at intake, research next, teach-back after, verdicts last. Never propose a verdict or ask about closure before delivering the digest.
This skill takes no tracker actions: its output is analysis plus drafted comments and rewrites, ready for the user to apply (or hand back for execution as a separate, explicit request). It earns its cost on issues old enough to have drifted from the code — epics and long-lived plans. Fresh, never-triaged issues belong to /triage; don't point this at an incoming bug report.
Grading discipline comes from /to-primitives. Tracker conventions (labels, milestones, auth quirks) come from whatever the repo documents — contributing docs, tracker docs, or the configuration /setup-skills established; read them first, and where the repo documents nothing, use the tracker's defaults and skip decoration advice.
Delivery rule. Whenever a turn ends in substantive analysis the user must read (the digest, the verdict proposals), that analysis must be the final prose message of its turn, with NO tool call after it — a question tool fired in the same turn swallows the analysis and the user never sees it. End such turns with questions written in plain prose, then stop and wait. Reserve question tools for short, self-contained choices with no analysis preceding them in the turn.
The argument is an issue number or URL. If none was given, ask which issue to audit.
Capture the product focus as context: read it from the repo's roadmap or planning docs where they exist, else ask the user for it in one sentence. It is the fulcrum every verdict will turn on, so it must be stated, not improvised later. It scopes nothing before the verdicts — research stays comprehensive regardless — and it does not license early judgment: the sequencing rule above still holds. These are the only questions allowed before the digest.
Treat every codebase claim in every body as unverified — the bodies froze at createdAt. Fan out read-only research agents, one per issue in the tree, in batches of no more than four at a time; if the tree holds more than ~8 issues, confirm the scope with the user before launching. Each agent returns:
file:line evidence. Cited line numbers, constants, and commit hashes drift; find the current location./to-primitives (exists / partial / missing, behavior-named, file:line-cited).Present to the user, in this order — this is the deliverable of the first half:
The delivery rule applies. End the digest with two gating questions in plain prose, then stop and wait for the reply:
Apply the roadmap test, not the complexity test: "does the stated product focus need this capability soon?", never "does the user story sound ambitious?" — an ambitious story may just mean the audit composed a maximal one.
For each issue propose: keep as-is (motivation and sketch both survived verification), rescope (capability needed near-term, body needs rewriting against current code), or close as premature (real capability, but the focus needs none of it).
Think independently: if the user's framing is wrong, say so with evidence; if one issue in a tree deserves a different fate than the rest, argue it. Note hygiene fixes regardless (wrong labels, stale milestone, drifted size) where the repo documents conventions to check against. The delivery rule applies here too. Iterate until the user settles on a verdict per issue.
Produce, as suggestions for the user to apply — take no tracker actions yourself:
Done when every issue the user ruled on has its drafted comment or body in the final message, ready to paste or approve.
Stale since written: <each claim that no longer holds, with what replaced it and current file:line>.
Still genuinely missing: .
If re-filed: <the correct framing; the smallest real slice; constraints landed since that the design must satisfy>.