crap-analyzer
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods.…
Use after a feature passes Light Verify (CP7), to prove the tests actually catch bugs and, where the code warrants it, to formally check its invariants — Checkpoint 8. Runs the refinement-advisor, then the picked tools — introversion scan, mutation testing, and opt-in TLA+ /
$ npx -y skills add swingerman/disciplined-agentic-engineering --skill harden --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/hardenContext preview
The summary Claude sees to decide when to auto-load this skill.
Use after a feature passes Light Verify (CP7), to prove the tests actually catch bugs and, where the code warrants it, to formally check its invariants — Checkpoint 8. Runs the refinement-advisor, then the picked tools — introversion scan, mutation testing, and opt-in TLA+ /
name: harden description: Use after a feature passes Light Verify (CP7), to prove the tests actually catch bugs and, where the code warrants it, to formally check its invariants — Checkpoint 8. Runs the refinement-advisor, then the picked tools — introversion scan, mutation testing, and opt-in TLA+ / Lean verification. Triggers — "/engineer.harden", "harden this feature", "Checkpoint 8", "which hardening does this need", "formally verify the feature".
Checkpoint 8. Acceptance tests show the feature works. Harden checks whether the tests would notice if it stopped working, and, for code with a real invariant, whether that invariant can be broken at all.
Tool choice comes from `/engineer.refinement-advisor`, not from a fixed list. Formal verification is worth its cost on a retry loop, and a waste on a CRUD endpoint.
applies. Writes a CP8 handoff.
Step 0 feature gate, write results into the fix record's `harden_results`, and write no CP8 handoff (fix owns its own close).
**Step 0 — Entry gate** (feature mode). Run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir> --through 7`. On a non-zero exit, stop and show the gap to the human. Then run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_branch.py <feature-dir>`. On a non-zero exit, stop. After both pass, show the breadcrumb (`${CLAUDE_PLUGIN_ROOT}/scripts/dae_progress.py <feature-dir>`, advisory) and create one TodoWrite todo per step. See `${CLAUDE_PLUGIN_ROOT}/references/progress-indicator.md`.
**Verification independence:** CP8 runs on a non-implementer agent (`agent_id` ≠ CP5's; enforced by `dae_handoff.py gate()`).
1. **Resolve + scope.** Resolve the root and manifest via `${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py`. Scope = changed code. Load `acs.md`, `spec.md`, `CHARTER.md`, and the CP7 handoff's `crap_results` block (arch-check records crap-analyzer's output there). In fix mode, or if the block is missing, run `crap-analyzer` on the scope first. 2. **Advise.** Run `/engineer.refinement-advisor` with `stage: harden` over the scope, passing it `crap_results`. Effective autonomy decides who picks the checks (see the advisor's *Who decides: autonomy*):
records `{skipped: <the advisor's reason, or "not selected">}` in its `harden_results` field, so the decision is visible, not silent.
Record the table, what was selected, and who decided (`decided_by: advisor | human`) in `harden_results.advisor`. 3. **Introversion pre-scan** (if selected). Run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_introvert.py <methodology-root>`. It flags tests that can pass without asserting on SUT output. The script defers to `manifest.introversion.backend` when set. Any non-`ok` status is advisory. Dispatch an agent to confirm each finding. For each confirmed vacuous test, write a real assertion and re-run. Record `harden_results.introversion`. 4. **Mutation** (if selected). Run `atdd:atdd-mutate` on the touched files, then `atdd:kill-mutants` on the survivors. If a test was flagged in Step 3 **and** carries a surviving mutant, it is almost certainly vacuous. Record `harden_results.mutation_score`. 5. **Formal checks** (selected TLA+/Lean rows only). Dispatch one **plain subagent** (default isolation, **not a fork**) per pick, `subagent_type: engineer:formal-verifier` (or the project override): `/engineer.tlaplus` for interleaving/state-machine targets, `/engineer.lean` for all-inputs targets. Each brief gives:
written"
reproduced against the real code"
Picks for different targets are independent, so dispatch them in parallel. Handle each result as follows:
a proof; Lean with no `sorry` and clean `#print axioms` is.
failing test (red), fix, go green, and re-run both test streams. If the fix would change AC-observable behavior, stop and route to `/engineer.feature-edit`. Harden does not rewrite the contract.
`provisional` and do not fix the code.
advisory, and don't block on them.
Record `harden_results.formal[]`: `{tool, target, invariant, verdict: holds|violated|provisional, bound_or_proof, finding}`. 6. **Arch re-check.** Harden may have changed code, so re-run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_arch.py <methodology-root>`. Record `harden_results.arch_check`. 7. **Handoff** (feature mode). Emit per `${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md` with `checkpoint: 8`. The `exit_criteria` block asserts:
skipped with a reason)
(`verified_by: tool`). Both are percentages, 0–100.
pinned by a test that fails on the old code
`recommended_next`: "open PR / `/engineer.progress-log`".
harden_results:
advisor: {decided_by:A methodology kit for engineering-led AI development — spec-driven, test-driven, charter-bound. ATDD + mutation testing + deterministic guardrails. AI agents do the typing. Engineers stay in charge of architecture, behavior contracts, and verification.
Repo: swingerman/disciplined-agentic-engineering
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods.…
Use to check a feature's code against the charter's architecture rules — dependency layering, cycles, forbidden patterns, file naming, file size. Triggers —…
Use to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a project-specific test pipeline, and…
Use when a single DAE artifact has ambiguities to resolve. Triggers — "/engineer.clarify", "clarify this spec", "resolve ambiguities", "this is vague — tighten…
Use to validate DAE artifacts for schema correctness and cross-artifact consistency. Triggers — "/engineer.consistency-check", "check consistency", "validate…
Use when a Ready feature needs its acceptance criteria discovered before specs are written. Triggers — "/engineer.discover-acs",…