Skip to content
Testing
Skill

/consistency-check

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".

From plugin
atdd
14922 skills2 agents4 commands2 hooks
Install
$ npx -y skills add swingerman/disciplined-agentic-engineering --skill consistency-check --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/consistency-check

Context 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".

SKILL.md

consistency-check.SKILL.md
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".

consistency-check

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`.

When to use

Before major pipeline transitions and as a CI gate.

  • **Feature scope** — `/engineer.consistency-check <slug>` — one feature's artifacts
  • **Project scope** — `/engineer.consistency-check --project` — project-wide invariants

**Not for:** fixing inconsistencies (run the suggested fix skill); within-one-artifact ambiguity (`clarify`); code risk (`crap-analyzer`).

Workflow

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.

Feature-scope checks

| 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.

Project-scope checks

| 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 |

Handoff

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.

References

  • `${CLAUDE_PLUGIN_ROOT}/references/ontology.md` — the *(ontology)* rows: what `dae_ontology.py` decides and why the rest stays here
  • [Foundation Design](https://www.notion.so/3585ecdee0e2811bbc67ff4913c03207) — every schema checked here
  • [Tracker Integration](https://www.notion.so/35a5ecdee0e28168b1aee324c267fd13) — `tracker_ref` resolution
Read more
Ships withatdd

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.

Get the whole plugin
Stats
149
Stars
10
Forks
Active
Maintenance
Python
Language
MIT
License
3d ago
Last commit
7mo ago
Created

Repo: swingerman/disciplined-agentic-engineering

Other skills on atdd.

atdd
Skill

atdd

Use to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a project-specific test pipeline, and…

@swingerman@swingermanView Skill
clarify
Skill

clarify

Use when a single DAE artifact has ambiguities to resolve. Triggers — "/engineer.clarify", "clarify this spec", "resolve ambiguities", "this is vague — tighten…

@swingerman@swingermanView Skill