// Implement one phase of ./specs/91-impl-plan.md end-to-end, matching the specs and project quality bars, then review the diff and fix valid findings before declaring done. Use when the user asks to build a phase, milestone, next phase, or roadmap slice.
Vendor reference repos as git submodules under ./vendors and produce deep research memos under ./docs/research covering architecture, design, key data structures, and load-bearing algorithms. Use whenever the user asks to research, study prior art, spike an assumption, compare upstream repos, or learn from pasted GitHub URLs before design or implementation.
Turn a feature idea or rough requirement into a complete, dependency-ordered spec set under ./specs, including PRD, design docs, roadmap, implementation plan, glossary, key decisions, and index updates. Use for non-trivial design, phasing, PRD, roadmap, or implementation-plan requests.
Implement one phase of ./specs/91-impl-plan.md end-to-end with high quality bars (correctness, elegance, performance), then run an independent code review against the relevant specs and fix every valid finding before declaring done. Use whenever the user says "build phase N", "implement the next phase", "land M0/M1/M2/M3", "follow the impl plan", "ship phase X entirely", "based on @specs/91-impl-plan.md think ultra hard and build phase X", or asks for a phase-shaped slice of the spec set. Trigger even when the user does not say "impl" if they reference an impl plan / roadmap milestone and ask Claude to build it.
Vendor reference repos as git submodules under ./vendors and produce deep research memos under ./docs/research covering architecture, design, key data structures, and load-bearing algorithms. Use whenever the user says "do research on X", "study how Y works", "submodule this repo and look into it", "understand the design of Z before we start", "spike on …", references prior-art crates / repos that should be evaluated, or asks to refer to ./vendors before designing or implementing. Trigger even when the user does not say the word "research" if they paste GitHub URLs and ask Claude to learn from them, compare alternatives, or extract patterns.
Turn a feature idea or rough requirement into a complete, dependency-ordered spec set under ./specs — PRD, component designs, glossary, security/perf/test cross-cuts, key-decisions log, stakeholder roadmap, and engineer-facing implementation plan — cross-referenced with prior-art memos in ./docs/research and vendored code in ./vendors. Use whenever the user says "write the spec", "design this", "let's plan X", "produce a PRD / impl plan / roadmap", "restructure the specs", "review and re-organise the design", "think ultra hard and split this into phases", or describes a non-trivial system that needs a written design before code. Trigger even when the user does not say "spec" if they ask for phased delivery, milestone exit criteria, or a build-order graph.
| name | impl |
| description | Implement one phase of ./specs/91-impl-plan.md end-to-end, matching the specs and project quality bars, then review the diff and fix valid findings before declaring done. Use when the user asks to build a phase, milestone, next phase, or roadmap slice. |
Use this Codex skill for phase-shaped implementation from
specs/91-impl-plan.md. The canonical workflow is the Claude impl skill at
.claude/skills/impl/SKILL.md; follow it, with the Codex-specific adjustments
below.
AGENTS.md, CLAUDE.md, specs/91-impl-plan.md, cited specs, and
relevant docs/research/ memos before editing.git status --short before edits and avoid
broad staging commands.specs/93-improvements-review.md.specs/91-impl-plan.md.CLAUDE.md; fix valid in-phase
findings.cargo build --workspace --all-targets
cargo test --workspace --all-targets
cargo +nightly fmt -- --check
cargo clippy --workspace --all-targets -- -D warnings
RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps
For boundary modules and external-input paths, also run the stricter Clippy
command from AGENTS.md. Run cargo deny check and cargo audit if
dependencies change.
No TODOs, placeholders, dead-code suppressions, unsafe, unwrap, or
expect in production paths. Public surfaces need docs and tests. Spec
adherence is binary: if implementation and spec disagree, stop and reconcile
the mismatch in writing before continuing.