菜单
Use when a feature has ACs and specs and needs an architecture plan before implementation. Triggers — "engineer plugin -> plan skill", "plan this feature", "plan the implementation", "design the architecture".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze changed code for complex, under-tested functions using CRAP scoring; produce ranked refactor and test recommendations.
Validate strict DAE quality gates after implementation-affecting changes, require machine-readable evidence, and write the quality-gate summary before completion or release.
This skill should be used when the user asks to "run mutation testing", "mutate my code", "kill mutants", "check test quality", "find surviving mutants", "verify test effectiveness with mutations", "run stryker", "run mutmut", "run pitest", "set up mutation testing", "how good are my tests", "are my tests catching bugs", or mentions mutation testing, mutation score, or mutant survival in the context of testing. It adds a third validation layer to the ATDD workflow: after acceptance tests verify WHAT and unit tests verify HOW, mutation testing verifies that tests actually catch bugs.
This skill should be used when the user asks to "build a feature", "implement a feature", "add functionality", "start development", "write acceptance tests", "write specs", "use ATDD", "use TDD with acceptance tests", or begins any feature implementation work. Also available as the atdd plugin's main skill. Enforces the Acceptance Test Driven Development workflow: write Given/When/Then specs before code, generate a project-specific test pipeline, and maintain two test streams.
This skill should be used when the user asks to "build a feature with a team", "use ATDD with agents", "create an ATDD team", "set up a team for ATDD", "orchestrate agents for ATDD", "use team-based development", "coordinate agents for feature development", "run the ATDD workflow with teammates", "add ATDD to my team", "extend my team with ATDD", "join the team with ATDD agents", "add spec-writer and reviewer to the team", or "add ATDD roles to the existing team". It orchestrates a six-phase ATDD workflow — spec writing, spec review, pipeline generation, implementation, refine, verify & harden — spawning a fresh agent per phase so no agent erodes across a long-running feature.
Analyze surviving mutants from a mutation testing run and write targeted unit tests to kill them. Re-runs mutations to confirm kills.
| name | plan |
| description | Use when a feature has ACs and specs and needs an architecture plan before implementation. Triggers — "engineer plugin -> plan skill", "plan this feature", "plan the implementation", "design the architecture". |
Produce a feature's architecture plan — Checkpoint 4, the most consequential architectural checkpoint. Where engineering authority over code design and performance is exercised: the agent proposes, the human decides.
Mixed mode — the agent proposes the architecture, the human confirms it, then the rest of the plan is drafted.
After discover-acs (Checkpoint 2) and atdd plugin atdd skill (Checkpoint 3). Produces plan.md.
If spec.md is missing, warn — planning should follow spec formalization — but the user may override and plan from acs.md alone (flag the skipped step in the handoff).
Not for: Given/When/Then specs (atdd plugin atdd skill); small changes to an existing plan (feature-edit).
Step 0 — Entry gate. Before starting, verify the prior checkpoint is complete: run ${PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir> --through 3. On a non-zero exit, stop and surface the gap to the human — do not proceed.
Verify branch hygiene: run ${PLUGIN_ROOT}/scripts/dae_branch.py <feature-dir>.
On a non-zero exit, stop and surface the message to the human — switch
branches and re-invoke. The check honors the git.manual: true manifest
opt-out.
After the gate passes, show the pipeline breadcrumb: run
${PLUGIN_ROOT}/scripts/dae_progress.py <feature-dir> and present its
output to the human — it shows where this checkpoint sits in the DAE pipeline.
The breadcrumb is advisory: a non-zero exit or a missing progress.md never
blocks the skill. Then create one Codex plan item per workflow step below. See
${PLUGIN_ROOT}/references/progress-indicator.md.
${PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md); load feature.md, acs.md, spec.md, CHARTER.md.CHARTER.md. Produce the two-part structured check: a compliance table (one row per charter rule, plus auto-rows for autonomy stance, verification independence, mutation policy, and — at high autonomy — performance budgets), and an Amendments section. Hard rule: never finish a plan with a ⚠️ deviation that lacks a matching amendment ADR. Either write the amendment inline, or stop and emit a handoff with human_action_needed: decision.plan.md — frontmatter (slug, checkpoint: 4, plan_status, created) + sections: Architecture, Charter Check, Phasing, Performance budgets, Collaboration schedule, Execution modes, Test strategy. Test strategy must explicitly incorporate feature.md's validation_method if it carries a non-default value — e.g. if validation_method is "canary 5% prod for 24h, watch dashboard X," the Test strategy section names the canary phase, the dashboard, and the rollback trigger. If validation_method is absent, default to the standard DAE stack (acceptance + unit + mutation per charter) and say so explicitly.plan.md has phasing (stages/slices), not a task list — tasks emerge from specs (one spec = one TDD cycle), driven by atdd plugin atdd-team skill.
Emit per ${PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: 4; recommended_next: "atdd plugin -> atdd-team skill to implement against the specs". If a deviation needs a decision, human_action_needed: yes (decision).
The handoff MUST include the exit_criteria block asserting each of Checkpoint 4's exit criteria (Foundation Design Section 8) with verified_by, met, and evidence. For verified_by: tool criteria, the evidence MUST be the tool's actual output. The checkpoint is marked done only when every criterion is met.