菜单
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.
用 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 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.
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.
| name | stub-first-planning |
| description | 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. |
A two-page spec is a spec nobody reads. The human skims it, rubber-stamps it, and the one load-bearing decision buried on page two ships unexamined. Length is not thoroughness, it's cover. So move the approval to the smallest thing that still carries the real decisions.
This applies to any planning artifact a human signs off on before work starts: a spec, an implementation plan, or a dispatch brief long enough that it's going to get skimmed instead of read.
Before you write the full artifact, emit a stub and stop:
root-cause-first).Five is a default, not a law. A tight, bounded stub is the point, and if the thinking doesn't fit in roughly ten bullets, it isn't done yet. Get explicit human approval on the stub before going further. Don't write the full artifact first and hand-summarize it back - the stub is the thing under review, and writing the long version first defeats the whole move.
Elaborate. Generate the full artifact from the approved stub. The stub is now the contract: the full version fills it in, it doesn't relitigate it. If elaboration turns up a decision the stub got wrong, that's a new stub bullet to re-approve, not a quiet edit buried in the long version.
Adversarially review the full artifact, scaled to stakes. The stub gate is in front of the pack's standing pre-merge red-team (see verification-gates), it does not replace it.
Judge stakes with the same rules the pack already uses for stopping and reviewing (see escalation-policy), not by feel.
The stub is a gate, not a summary. It puts the human's attention at the front, where the decisions are still cheap to change, and it keeps the expensive review - human and adversarial both - off a document that was going to get skimmed anyway. Shorter is a side effect. The point is where the approval happens.
root-cause-first - the 5 problem bullets are mechanisms, not symptoms.dispatch-brief - a long brief is a planning artifact; stub it before you compile the full ten-block contract.verification-gates - this is the front gate; that's the done gate.