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".
Scanned 9/5/2026
Install to Claude Code
npx -y skills add swingerman/engineer --skill consistency-check --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Consistency Check?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/swingerman-consistency-check-engineer)More formats (shields.io, HTML) on the badges page.
---
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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!