菜单
Use when a Ready feature needs its acceptance criteria discovered before specs are written. Triggers — "engineer plugin -> discover-acs skill", "engineer plugin -> acceptance-criteria skill", "discover ACs", "what must this feature do", "figure out acceptance criteria".
用 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 | discover-acs |
| description | Use when a Ready feature needs its acceptance criteria discovered before specs are written. Triggers — "engineer plugin -> discover-acs skill", "engineer plugin -> acceptance-criteria skill", "discover ACs", "what must this feature do", "figure out acceptance criteria". |
Discover a feature's acceptance criteria — Checkpoint 2. ACs are decisions about what behaviors must work, in domain language. They precede the Given/When/Then formalization that atdd plugin atdd skill produces.
Separating AC discovery (divergent decisions) from spec formalization (convergent encoding) is what protects domain language from leaking into implementation language.
On a feature with autonomy_level set and status of ready (greenfield) or in-progress/done (onboarded existing work). Produces acs.md.
Two modes:
status: ready, no existing spec. Discover ACs from scratch via the four-pass interview.in-progress/done) that already has a spec (a Speckit spec.md, a design doc, shipped code). Extract candidate ACs from the existing material, then interview only for the gaps it leaves.Not for: a parked feature (discuss to promote first); a feature that already has a complete acs.md (feature-edit); producing Given/When/Then specs (atdd plugin atdd skill); deciding whether to build the feature (discuss).
Step 0 — Entry gate. Before starting, verify the prior checkpoint is complete: run ${PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir> --through 1.5. 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.
Resolve + validate — resolve the methodology root + manifest via ${PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md); locate the feature. Reject if not found, if status: parked (→ discuss to promote first), or if acs.md already exists with content. Pick the mode: existing spec/code present → reverse-engineer; else → greenfield.
Load — feature.md, CHARTER.md, manifest.yml, prior handoffs/. Reverse-engineer mode: also load the existing spec / design doc / relevant code. For code lookup in reverse-engineer mode (surveying what exists, tracing what calls what), prefer LSP workspace-symbols / find-references when an LSP MCP capability is available; fall back to grep + Read otherwise. See ${PLUGIN_ROOT}/references/code-lookup.md.
Discover the ACs:
prompt the user with up to 4) rather than one-per-turn — the existing material already carries the bulk.The four passes:
Enforce domain language — when implementation leaks in ("returns 401", "the endpoint", table/class names), soft-warn and rephrase to the user-observable behavior; user confirms. Don't block — educate.
Handle scope drift — if a behavior surfaces outside feature.md's outcome, offer three options: broaden feature.md, drop as out-of-scope, or park a separate discuss. User picks.
Coverage check — before writing, report ACs captured + which passes were covered; if a pass was skipped, prompt once.
Write acs.md — YAML frontmatter (ac_count, high_priority_count, discovered) + numbered ## AC-N: <name> sections, each with Priority, Type, and a domain-language body.
Handoff — emit a summary.
Re-invoking on a feature with existing acs.md is an edit pass (preserve AC IDs). Big restructures → feature-edit.
In reverse-engineer mode, note in the handoff that acs.md and the original spec should later be reconciled — a good consistency-check target.
Emit per ${PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: 2; human_action_needed: yes (review); recommended_next: "engineer plugin -> atdd skill to formalize as Given/When/Then specs" (greenfield), or "engineer plugin -> consistency-check skill to reconcile acs.md against the existing spec" (reverse-engineer).
The handoff MUST include the exit_criteria block asserting each of Checkpoint 2'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.