菜单
Implements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: for each Done-When item, write a failing test first, then the minimum code to make it pass (red-green).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Decomposes underspecified requests by classifying gaps (missing info, ambiguity, false premises) and generating targeted clarifying questions. Produces a confirmed problem statement before any implementation begins. For sharpening a request that already exists; not for open-ended requirement discovery from a vague idea (use the research command).
Implements the Standard/Full planning pipeline for Medium and Complex tasks: multi-step discovery, phase decomposition with skill matching, cross-cutting concerns, and plan emission with Gate fields.
Placeholder skill directory required by skill-eval's run_eval tool signature. This benchmark runs configurations=['without_skill'] only — we are measuring raw model tiers, not a skill — so this file's content is never mounted or read by a subject session.
Guides module and API design using APOSD principles: generates multiple design alternatives, compares them on information hiding and interface depth, and produces a documented design decision. For creating new module/API design; not for assessing existing designs (use aposd-reviewing-module-design) or routine-level design (use cc-routine-and-class-design).
Assesses existing module and interface design for complexity symptoms: information leakage, shallow interfaces, pass-through layers, and unknown unknowns. Produces a structured assessment — not transformations (use aposd-simplifying-complexity to edit) and not new-design generation (use aposd-designing-deep-modules).
Transforms complex code by applying APOSD's pull-complexity-downward principle: resolves error hierarchies, collapses configuration, and moves caller-side logic into modules. Produces edited code; not for assessment-only review (use aposd-reviewing-module-design) or designing new modules from scratch (use aposd-designing-deep-modules).
| name | build-doctrine |
| description | Implements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: for each Done-When item, write a failing test first, then the minimum code to make it pass (red-green). |
Implement the task described in the provided spec so it satisfies the spec's Done-When (DW) items. Write all code and tests to the exact output paths the spec names.
Test-driven, one DW item at a time. For each DW item:
test_DW_1_1_parses_hours). Run it; confirm it fails for the right reason.Your tests come from the DW items: each DW item gets test(s), and that is the test suite.