菜单
Non-obvious proof: Use when accepted behavior needs dedicated test design before planning. Own proof obligations, deterministic oracles, proving layers, and the test-design handoff; Skip when obvious inline planning proof, executable test implementation, or test review is enough.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Root cause: Use when a Go bug, flaky test, build failure, hang, deadlock, timeout incident, or production regression needs causal diagnosis. Own the first broken invariant and, only when authorized, the smallest causal fix and replayed proof; Skip when feature implementation, unresolved policy design, broad review, or claim-only verification is primary.
Pressure-test: Use when existing research or framing needs a few independent, discriminating questions before specification or planning. Own hidden assumptions, ownership, failure semantics, irreversible consequences, and rollout risk, plus the next owner; Skip when framing is blank, ordinary spec review is needed, or one isolated high-impact approval question is primary.
Approval question: Use when one candidate-spec decision is high-impact, hard to reverse, or explicitly challenged. Own a read-only pressure test with evidence, options, a recommended option, and decision owner; Skip when framing is blank, whole-spec review is needed, or the clarification is low-impact.
Problem frame: Use when a chosen or mostly chosen feature/refactor direction still needs an engineering-ready behavior delta, scope, constraints, assumptions, and readiness decision. Own that frame, its decided defaults, surviving user-owned questions, challenge routing, and next owner; Skip when raw ideation, final design decisions, or task breakdown is primary.
Delivery platform: Use when CI/CD gates, release trust, drift controls, containers, migrations, or rollout policy needs a decision, or when changed delivery controls need conformance review. Own delivery acceptance and review; Skip when API, data, security, reliability, or pipeline implementation is primary.
Test strategy: Use when accepted behavior needs risk scenarios, proof levels, deterministic oracles, or executable gates, or when changed tests and validation evidence need review. Own proof design and test conformance; Skip when behavior is unresolved, tests must be implemented, or completion claims need validation.
| name | test-design-session |
| description | Non-obvious proof: Use when accepted behavior needs dedicated test design before planning. Own proof obligations, deterministic oracles, proving layers, and the test-design handoff; Skip when obvious inline planning proof, executable test implementation, or test review is enough. |
Must read Test Design; it owns proof disposition, the review trigger, and the planning boundary. Build the smallest falsifiers needed for non-obvious accepted risks and keep obvious proof inline. Apply root self-review and use independent review only when triggered. Carry dispositioned concerns forward; seek fresh review only after FAIL repair or material candidate change. Stop when Test Design permits planning or reopens specification or design.
