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 check a feature's code against the charter's architecture rules — dependency layering, cycles, forbidden patterns, file naming, file size. Triggers — "/engineer.arch-check", "architecture check", "check architecture fitness", "does this follow the charter", "check
$ npx -y skills add swingerman/disciplined-agentic-engineering --skill arch-check --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/arch-checkContext preview
The summary Claude sees to decide when to auto-load this skill.
Use to check a feature's code against the charter's architecture rules — dependency layering, cycles, forbidden patterns, file naming, file size. Triggers — "/engineer.arch-check", "architecture check", "check architecture fitness", "does this follow the charter", "check
name: arch-check description: Use to check a feature's code against the charter's architecture rules — dependency layering, cycles, forbidden patterns, file naming, file size. Triggers — "/engineer.arch-check", "architecture check", "check architecture fitness", "does this follow the charter", "check layering".
Run the charter architecture fitness check — Checkpoint 7 (Light Verify), alongside `crap-analyzer`. Turns the charter's architectural vision from prose into an objective gate: `dae_arch.py` reads the manifest's `architecture:` rules and reports violations.
Read-only on the codebase — it reports, it does not fix.
Checkpoint 7, after the feature's code is implemented and refined. Also useful as a standalone audit (`--full`) of an existing project.
**Not for:** change-risk analysis (`crap-analyzer`); artifact consistency (`consistency-check`); fixing violations (that is a human/agent decision per violation).
Verify the prior checkpoint is complete: run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir> --through 6`. On a non-zero exit, **stop** and surface the gap to the human.
Verify branch hygiene: run `${CLAUDE_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 `${CLAUDE_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 TodoWrite todo per workflow step below. See `${CLAUDE_PLUGIN_ROOT}/references/progress-indicator.md`.
Run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_arch.py <methodology-root>` (add `--full` for a whole-project audit). If it reports "no `architecture:` section", tell the user the charter has no machine-readable architecture rules yet and stop.
Group the violations by kind (layering first — it is the architectural-vision core). For each, show `file:line` and the rule. Do not auto-fix.
For each violation, the human decides: a real break (fix the code), or a rule that no longer fits (amend `manifest.architecture` — and the charter prose). `dae_arch.py` exiting non-zero means Checkpoint 7's architecture-fitness exit criterion is unmet until the violations are resolved.
If `features/<slug>/runbook.md` exists, check that every step blocking a deploy-related AC is `completed: true`. If any blocking step is open while its dependent AC is asserting `met: true`, surface it as a verification gap and refuse to mark CP7 complete. The runbook's `blocking_acs` list is the source of truth — see `engineer/skills/plan/references/runbook-template.md`.
Emit a summary per `${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md`. `checkpoint: 7`; the `exit_criteria` block asserts the architecture-fitness criterion with `verified_by: tool` and the `dae_arch.py` exit status as evidence.
the `architecture:` manifest section (§2); the Checkpoint Exit Contract (§8)
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 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",…
Use when exploring a feature idea before committing, or revisiting a parked one. Triggers — "/engineer.discuss", "/engineer.discuss <slug>", "I have an idea…