메뉴
Use when declaring any work item done, or when writing the report/evidence block of a dispatch brief. Defines the gate list — the specific evidence required before something counts as done — per class of work, plus universal rules that apply to every class.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use at the polish stage of a design direction, once structure is settled, to turn a prototype's own tokens into a small panel of eye-decidable knobs a designer drives by hand, and to route what they settle back into the token system and the taste rules. Emits an altitude-appropriate facet spec, and at polish a self-contained tunable playground. Skip it when the artifact has no eye-tunable surface.
Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet.
Use before grounding a design or technical direction in external references — comparing tools, evaluating approaches, gathering prior art — before committing to a direction. Produces a source index, a synthesis, and concrete candidate directions instead of a pile of links.
Use before writing any planning artifact a human has to approve - a spec, an implementation plan, or a long dispatch brief. Gate the full artifact behind a tight stub the human will actually read, get approval on the stub, then elaborate and adversarially review the full thing.
Use when receiving a design or code review to execute, or when writing a review someone else will execute. Splits every review item into one of four buckets before any work starts, so parked items don't get silently rebuilt and outgoing reviews arrive pre-executable.
Use any time more than one lane of work (delegate, agent, or workstream) is active against the same project. Maintains board.json as the single source of truth for lane state — written on every lane transition, not batched — so status reporting, "what's running", handoffs, and kill decisions are all queries against one file instead of reconstructed from memory.
| name | verification-gates |
| description | Use when declaring any work item done, or when writing the report/evidence block of a dispatch brief. Defines the gate list — the specific evidence required before something counts as done — per class of work, plus universal rules that apply to every class. |
"Done" is not a feeling, it is a gate list. Different classes of work fail in different, predictable ways, so each class has its own required evidence. Find the closest matching work class below and gather every item on its list before declaring done. These lists are a floor: a repo's own constants can extend them (see Extending, below), never shrink them.
Review-bot triage is part of done. An automated reviewer's comments are not optional feedback for later — triaging every comment (fix it, dismiss it with stated reasoning, or park it with a written reason) is itself a required gate. A change is not done while an automated review comment sits untriaged, even if every other gate passed.
Stale-premise rule. Before executing a work item, check whether its stated premise still holds — the thing it says to add might already exist, the bug it names might already be fixed, the config it assumes might have already changed. When reality contradicts the brief, report the discrepancy with evidence instead of executing anyway. A no-op backed by evidence is a valid, completed outcome, not a failure to act.
Bounded-temporary rule. Every temporary path, flag, stub, or band-aid must state its removal criterion and have a filed follow-up task. Without both, it is not temporary, it is permanent scaffolding wearing a temporary label. The difference between a migration step and scaffolding is exactly this: a migration step names the condition under which it goes away ("remove once X ships," "remove after the last consumer of Y migrates"); scaffolding has no such condition, or only a vague one like "revisit later." File the follow-up in the tracker of record for the active context — read from constants' tool_mapping — not whichever tracker CLI happens to be on hand; a follow-up filed in the wrong tracker is invisible to whoever actually owns it and doesn't satisfy this rule.
A change matching this gate's risk criteria does not merge on green checks and an author's own "done" report alone. It also gets an independent adversarial review, commissioned before the merge — not requested after, and not skipped because the diff looks small or the report sounds confident.
Risk criteria (the applicability gate). This review is required whenever a change matches any of:
A repo's own constants may name additional risk criteria on top of this base list. Treat that the same as the gate-list extension mechanism below: additive only, never a way to narrow the baseline.
The reviewer must be independent. Its identity is read from constants (repo or personal scope, per your own setup) — never chosen ad hoc by whoever is running the merge. "Independent" has exactly one meaning here: a genuinely different agent or tool than the one that authored the change. Not the same runtime re-invoked in a fresh context. Not a second pass by the same session. Never the author reviewing itself. An author's offer to self-review — however well-intentioned, however much time it would save — is declined outright; it is not a lighter-weight version of the required review, it is not the required review at all.
If the designated reviewer is unavailable, that is escalated, never routed around. Report the block by name — which reviewer, why it's unavailable — and propose a wait or a named alternate. Do not silently substitute a self-review because nothing else is on hand, and do not silently drop the gate because the change is otherwise ready. Unavailability is exactly the moment this rule exists to hold; it is the least convenient time to skip it and the most important time not to.
Briefing the reviewer. Commission the review per the dispatch-brief skill, framed as refutation, not confirmation: find the missed edge case, the wrong assumption, the security hole, the simpler alternative. A reviewer asked to "check this looks okay" tends to produce a rubber stamp; a reviewer asked to find flaws produces a review.
Triage before merge. Sort every finding from the review into one of the feedback-triage skill's four buckets — fixed now, delegated, escalated as a real decision, or parked with a stated reason — before the change merges. This is the review-bot-triage universal rule above, extended to a commissioned reviewer instead of an automated one. A finding marked "addressed" with no diff or written rebuttal is untriaged, not done.
Named exceptions:
Escape hatch. A human with standing to accept the risk states, in the moment, that this specific change proceeds without the independent pass — and that statement is the record (in the merge instruction, the PR, or the board entry), not an inference drawn from silence. A merge that simply doesn't mention the missing review is an unlogged gap, not an invoked escape hatch.
Done means deleted. Before declaring this class complete:
A repo's own constants (a repo.yaml or equivalent) can add new work classes, or extend an existing class's gate list with landmines specific to that repo — a known-flaky consumer, a required staging step, an extra sign-off. When repo constants add a gate, it applies in addition to the list here, never instead of it.
The same applies to the adversarial pre-merge review above: a repo's constants name its designated independent reviewer and may add risk criteria beyond the base list, always additive, never a substitute for the reviewer being genuinely independent of the author.
