メニュー
Implements a coding task from a written spec with Done-When acceptance items. Use when given a spec to implement: write failing tests first then code to pass (red-green), covering the Done-When items and important behavior beyond them.
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: write failing tests first then code to pass (red-green), covering the Done-When items and important behavior beyond them. |
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, working red-green, one behavior at a time:
Cover every DW item — that is the floor, not the ceiling. Then go past the DW list: write failing tests first for the edge cases, error paths, and boundaries you anticipate too, even when no DW item names them. Name DW-item tests for their DW-ID (e.g. test_DW_1_1_parses_hours).
