菜单
Use when making or evaluating any behavior, plan, prompt, skill, code, test, or operational change that needs purpose, proof, consumer, or falsifier clarity.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a request needs product/design exploration, unclear requirements, multiple viable approaches, UI/UX choices, or new behavior whose intent is not yet bounded.
Use when 2+ independent tasks, failures, research lanes, exploration lanes, or path-scoped investigations can run without shared state, shared files, or sequential dependency.
Use when executing a written implementation plan inline in the current session with checkpoints and verification.
Use when adding or changing a capability surface such as a public function, API, command, prompt, workflow, schema/helper, policy, or reusable instruction.
Use when implementation is complete, verification passes, and the remaining decision is how to integrate, merge, PR, clean up, or finish the branch.
Use when creating or revising docs, plans, records, PR text, handoffs, or other prose that should be sparse, direct, and low-context.
| name | purpose-first-tdd |
| description | Use when making or evaluating any behavior, plan, prompt, skill, code, test, or operational change that needs purpose, proof, consumer, or falsifier clarity. |
Purpose comes first. Tests are executable purpose. Code and instructions exist to satisfy a real consumer.
Redteam forwarder: For falsifier validation, run /redteam:verify to cross-check that the falsifier actually catches the intended failure mode. A falsifier that never fires is not a real falsifier. For high-stakes contracts (security, billing, policy gates), use /redteam:review to validate the contract holds before declaring it done.
Purpose: make every change defensible before implementation. Consumer: agents planning, implementing, reviewing, debugging, or editing instructions. Failure consequence: changes optimize activity instead of value; tests prove implementation details instead of purpose; reviewers cannot tell what failure means. Falsifier: the change is purely cosmetic or self-contained with no behavior, policy, proof, consumer, or public-contract impact.
Before behavior changes, fill the canonical 9-field PDD contract:
purpose: why this exists.consumer: who or what uses it.contract: what the change must achieve.failureBoundary: what breaks or is contained when it fails.evidence: test, command, observation, trace, or invariant proving it.falsifier: executable or observable condition that would prove it wrong.nonGoals: what this intentionally excludes.invariants: truths that must remain true while changing it.assumptions: facts not yet proven.For behavior, plan, prompt, skill, code, test, or operational changes:
evidence/falsifier fields.If the task is operational/config-only, define the equivalent proof command or live-state check before changing it.
Any judgment call needs confidence and falsifier:
confidence=<level>; falsifier=<specific evidence that would change this>.
No falsifier means the decision is not ready.