菜单
Use before proposing any fix for a bug, test failure, performance regression, or unexpected behavior. Requires a stated causal mechanism before a fix is written, and treats a contradicted hypothesis as progress, not failure.
用 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 | root-cause-first |
| description | Use before proposing any fix for a bug, test failure, performance regression, or unexpected behavior. Requires a stated causal mechanism before a fix is written, and treats a contradicted hypothesis as progress, not failure. |
Reproduce → mechanism → fix the mechanism → prove with measurement.
Retries, widened timeouts, threshold bumps, heap increases, and similar changes sometimes ship anyway, under time pressure or as a stopgap. That is fine, as long as the change is labeled a symptom patch (not a fix) in the report, and a follow-up to find the actual mechanism is filed before moving on. An unlabeled symptom patch is the failure mode this skill exists to prevent.
When evidence contradicts the working hypothesis, that is a result, not a dead end. Report the contradiction explicitly and follow where it leads — the hypothesis was wrong, and finding that out is exactly what the reproduction loop is for. Do not quietly drop a contradicted hypothesis and move to a new one without saying so, and do not force-fit the new evidence into the old story.
docs/case-studies.md in this plugin has three non-normative worked examples tracing this loop end to end, including one where the mechanism-targeted fix was correct but exposed a second problem, requiring a second pass through the loop.
