菜单
Phase 5 of design thinking. Audit the implementation against the spec. Produces an audit document. Input: implementation from /prototype + spec from /define. Invoke after Prototype. NOT the same as /design-doc — this evaluates a specific implementation cycle, not the system's full architecture.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a repo, project, or area has accumulated several design/spec/plan docs and needs ONE coherent, top-down design document that synthesizes them and routes a reader to the right spec for depth. Create or update after a release or major implementation cycle, when onboarding needs a current architectural view, or when it is unclear which spec is current versus superseded. Trigger phrases: "update the design doc", "sync the design doc", "design-doc", "compile the design", "give me a top-down view of the design".
Phase 2 of design thinking. Synthesize understanding into a precise problem definition and spec. Produces a spec with explicit success/failure criteria. Input: context brief from /understand. Invoke after Understand, or when Ideate reveals the spec is too vague.
Entry point for the 5-phase design thinking process. Assesses current state and routes to the appropriate phase skill. Each phase runs in an isolated agent session and produces a concrete artifact. Phases: understand → define → ideate → prototype → test. Invoke when starting any non-trivial problem or creative task.
Phase 3 of design thinking. Generate and select an approach, then produce a concrete implementation plan. Input: spec from /define. Invoke after Define, or when Prototype reveals a fundamental design issue requiring replanning.
Phase 4 of design thinking. Execute the plan to produce a working artifact. Input: plan from /ideate and spec from /define. For code: uses superpowers execution skills. For writing/creative: produces the draft artifact. Invoke after Ideate.
Phase 1 of design thinking. Map the problem space thoroughly before defining or solving. Produces a context brief. Invoke at the start of any non-trivial problem, or when a later phase reveals the problem was not well understood.
| name | test |
| description | Phase 5 of design thinking. Audit the implementation against the spec. Produces an audit document. Input: implementation from /prototype + spec from /define. Invoke after Prototype. NOT the same as /design-doc — this evaluates a specific implementation cycle, not the system's full architecture. |
Using test to audit the implementation against the spec and produce an evaluation record.
Produce docs/dt/audit.md.
Read docs/dt/spec.md (the criteria) and examine the implementation from Prototype before doing anything else.
/test./prototype (implementation is wrong)./define (spec was wrong)./design-doc's job.docs/dt/audit.md. Use the frontmatter:
---
date: YYYY-MM-DD
phase: test
status: complete
verdict: PASS|PARTIAL|FAIL
---
docs(dt): complete test phase — <verdict>: <brief description>
Phase complete: Test — PASS
Artifact: docs/dt/audit.md
Cycle complete. Next options:
- Release or merge the implementation.
- Invoke /design-doc to update the architectural design document (recommended at release boundary).
- Start a new cycle with /understand or /design-thinking for the next problem.
Phase complete: Test — PARTIAL/FAIL
Artifact: docs/dt/audit.md
Critical findings require fixing. Next:
- Open a new agent session, invoke /prototype with docs/dt/audit.md as additional context alongside docs/dt/plan.md and docs/dt/spec.md.
- If the spec was wrong: invoke /define instead, using the audit's findings to correct the spec.
After a successful test, /design-doc is recommended but optional. Call it at a release boundary — when the implementation is stable and the architecture should be recorded for future contributors and agents. Do not call it mid-cycle.