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 to validate DAE artifacts for schema correctness and cross-artifact consistency. Triggers — "/engineer.consistency-check", "check consistency", "validate the artifacts", "are the specs and ACs in sync", "audit this feature".
$ npx -y skills add swingerman/disciplined-agentic-engineering --skill consistency-check --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/consistency-checkContext preview
The summary Claude sees to decide when to auto-load this skill.
Use to validate DAE artifacts for schema correctness and cross-artifact consistency. Triggers — "/engineer.consistency-check", "check consistency", "validate the artifacts", "are the specs and ACs in sync", "audit this feature".
name: consistency-check description: Use to validate DAE artifacts for schema correctness and cross-artifact consistency. Triggers — "/engineer.consistency-check", "check consistency", "validate the artifacts", "are the specs and ACs in sync", "audit this feature".
Cross-artifact validation for DAE — the methodology's take on Speckit's `/analyze`. **Read-only**: reports inconsistencies and suggests fixes; never mutates. Any agent may run it (mechanical validation, not judgment-heavy verification). `checkpoint: null`.
Before major pipeline transitions and as a CI gate.
**Not for:** fixing inconsistencies (run the suggested fix skill); within-one-artifact ambiguity (`clarify`); code risk (`crap-analyzer`).
1. **Resolve + load** — resolve the methodology root + manifest via `${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py` (see `references/resolving.md`). Feature scope: load every artifact in `features/NNN-<slug>/` + `CHARTER.md`. Project scope: load `CHARTER.md` + every `feature.md` frontmatter. For identifier lookups (does symbol X actually exist in the code?), prefer LSP find-definitions / workspace-symbols when an LSP MCP capability is available; fall back to grep + Read otherwise. See `${CLAUDE_PLUGIN_ROOT}/references/code-lookup.md`. 1.5. **Run the mechanical checks first** — `${CLAUDE_PLUGIN_ROOT}/scripts/dae_ontology.py <feature-dir>` (or `--project`). It executes every constraint that is a set operation over structured data — enumerations, functional properties, parent/child inverses, cycle detection, AC↔scenario coverage closure, Principle 7 disjointness — deterministically. Take its findings as given; do **not** re-derive them by reading the artifacts. They are tagged in the tables below as *(ontology)*. See `${CLAUDE_PLUGIN_ROOT}/references/ontology.md`. 2. **Run the judgment checks** (below) — the rows the script cannot decide. 3. **Report** — errors first, then warnings; each with location + a suggested fix (which skill to run). Do not apply fixes. 4. **Handoff** — emit a summary.
| Check | Severity | |-------|----------| | `feature.md` slug matches folder name *(ontology)* | error | | `feature.md` mandatory frontmatter present; `status: ready` ⇒ `autonomy_level` set *(ontology)* | error | | `acs.md` AC IDs unique + sequential; `ac_count` matches actual *(ontology)* | error | | Every AC has a covering `@AC-N` spec scenario; no scenario tags an AC that doesn't exist *(ontology)* | error | | `acs.md` ACs in domain language (implementation-leakage heuristic) | warning | | `acs.md` ACs cover the `feature.md` outcome | warning | | `relevant_adrs` reference ADRs that exist | error | | `spec.md` and `.build/spec.json` agree | error | | `plan.md` Charter Check: every ⚠️ deviation has a matching amendment | error | | **Validation method honored?** — if `feature.md` declares a non-default `validation_method`, `plan.md`'s Test strategy section must reference it (canary phase, dashboard names, rollback trigger, etc. as relevant) | warning | | Verification handoffs: `agent_id` ≠ implementer's (Principle 7) *(ontology)* | error | | `tracker_ref` resolves on the configured tracker | warning | | Handoff completeness: no checkpoint marked done in `progress.md` lacks a complete handoff | error | | `parent_feature` set ⇒ parent resolves and lists this in `child_features` *(ontology)* | error / warning |
The handoff-completeness check is the after-the-fact sweep for handoff-as-gate (Foundation Design Section 5): run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir>` — it flags any checkpoint marked done with a missing, `interrupted`, or unmet-`exit_criteria` handoff.
| Check | Severity | |-------|----------| | `CHARTER.md` section 5 roles == `manifest.team.default_roles` | error | | `manifest.yml` schema valid; enum values legal | error | | Feature folder numbering monotonic; no reuse *(ontology)* | warning | | One feature branch per feature; one feature per roadmap item *(ontology)* | warning | | `parent_feature` chains do not cycle *(ontology)* | error | | ADR not referenced by any feature in N months (N from manifest, default 6) | warning | | Every `features/*/` has a non-empty `feature.md` | warning | | `team.default_roles` includes `verifier` when independence enforced | error |
Emit per `${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md`. `checkpoint: null`; `artifacts: []`. Feature scope → handoff in that feature's `handoffs/`; `--project` scope → handoff in `.engineer/handoffs/`. Any errors → `human_action_needed: yes`. `recommended_next`: resolve via `clarify` / `feature-edit` / `plan`, then re-run.
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 when a Ready feature needs its acceptance criteria discovered before specs are written. Triggers — "/engineer.discover-acs",…
Use when exploring a feature idea before committing, or revisiting a parked one. Triggers — "/engineer.discuss", "/engineer.discuss <slug>", "I have an idea…