القائمة
Analyze changed code for complex, under-tested functions using CRAP scoring; produce ranked refactor and test recommendations.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
Use as a thin compatibility skill when the user asks for the old mutate command; delegate to atdd-mutate for mutation testing and differential mutation workflow.
| name | crap-analyzer |
| description | Analyze changed code for complex, under-tested functions using CRAP scoring; produce ranked refactor and test recommendations. |
CRAP (Change Risk Anti-Patterns) flags functions that are both complex and poorly tested — the worst-risk code to ship.
CRAP(m) = comp(m)² × (1 − cov(m))³ + comp(m)
This skill scopes analysis to a diff, ranks findings worst-first, and turns each finding into a concrete refactor + test-stub proposal.
When DAE runtime quality gates are active, CRAP evidence is mandatory by default after implementation-affecting edits. Write machine-readable gate evidence to features/<feature>/evidence/quality/crap.json and validate it with python3 plugins/engineer/scripts/dae_guard.py quality-verify before completion or release.
Determine the diff. First that works:
gh pr diff / gh pr diff <number> if a GitHub PR is referenced.git diff --merge-base <main-branch> — detect the main branch with git remote show origin | grep 'HEAD branch'.git diff --cached for staged changes.git diff HEAD~N..HEAD for a named commit range.Pipe the diff to scripts/compute_crap.py --diff -.
Locate or generate coverage. Let the script auto-discover coverage files first (lcov, Cobertura, JaCoCo, Clover, Go coverage.out, coverage.py JSON). If nothing is found, follow references/coverage-discovery.md to detect the toolchain, then ask before running it. On decline, proceed with coverage=0% and flag it in the report header.
Run the analyzer.
python3 <skill-dir>/scripts/compute_crap.py --diff - --repo-root <repo> --threshold <N> --format both
Default threshold is 20. Read .crap-analyzer.json at repo root if present and pass its threshold through. Full flag list and output JSON shape: references/script-reference.md.
For DAE quality gates, use the strict policy thresholds unless project config explicitly relaxes them with audit fields:
max_crap_score >= 30;max_crap_score >= 20;Evidence shape:
{
"schema_version": 1,
"gate": "crap",
"tool": "crap-analyzer",
"status": "PASS",
"generated_at": "2026-05-22T00:00:00Z",
"feature": "features/001-demo",
"changed_files": ["src/app.py"],
"coverage_source": "coverage.xml",
"thresholds": {
"max_crap_score": 30,
"warn_crap_score": 20,
"missing_coverage_policy": "assume_zero_and_fail_if_threshold_exceeded",
"max_high_risk_findings": 0
},
"summary": {
"changed_functions": 1,
"max_crap_score": 8.0,
"high_risk_findings": 0
},
"findings": []
}
Present the report. Show the markdown table. For each finding, link file:start_line. If more than ~8 findings, surface the top 5 and mention the rest.
Propose fixes per finding, worst-first. For each function above threshold:
When len(findings) >= 3, dispatch one subagent per finding in a single message — per-finding work is independent so parallelizing drops wall-clock from O(n) to O(1). Prompt template + aggregation rules: references/subagent-prompt.md. After subagents return, sort by CRAP descending and sanity-check every "safe to auto-apply" claim against step 7.
Present the wrap-up menu. Dispatch refactor / test-stub work via prompt the user. Menu structure and apply loop: references/wrap-up-menu.md. "Safe refactor" = pure extract-method with no behavior change (same inputs → same outputs, same side effects, same order). One Edit per action; confirm each before applying.
Never auto-apply:
await, .then, subscribe, promise chains, RxJS / coroutine / goroutine ordering).### 1. `file.py:42` — `do_thing` (CRAP 240)
**Why it's flagged:** complexity 15, coverage 0% (no tests touching body).
**Refactor proposal:**
<unified diff or code block>
**Test stubs to add:**
<framework-appropriate test block>
Keep each section tight — one paragraph of "why", diff, stubs. No preamble.
Optional .crap-analyzer.json at repo root:
{ "threshold": 20 }
Read if present, pass --threshold to the script. No other keys for now.
engineer owns the cross-plugin blocking gate.