spec-lintlisted

Lint the project's specification docs (requirements / design / plan / task markdown): orphan specs, dead cross-doc links, index and naming drift, empty sections, stale TODOs, and — most importantly — reverse consistency between layers (design must cover its requirements, plans must cover their design). Auto-detects which spec-driven framework is in use — Kiro IDE, Superpowers, OpenSpec, GitHub spec-kit, BMad Method, GSD, or a generic default profile — and applies that profile's rules. Use when the user asks to lint, audit, or health-check spec docs ("/spec-lint", "check the specs", "spec health check"), asks whether design covers requirements or plans match the design, reports orphan specs or broken spec links, or names a supported framework in a context that implies auditing its spec artefacts.
kevinlin/skills · ★ 3 · Code & Development · score 74

Install: claude install-skill kevinlin/skills

# spec-lint: Multi-Profile Specification Doc Health Check Lint specification markdown produced during a spec-driven workflow. The goal is a clean, navigable spec tree where: - A root index (or equivalent registry) lists every spec file. - Each layer is consistent with the layer above it (design covers requirements; plan covers design). - Cross-doc links resolve. - Naming, structure, and metadata follow the conventions of the toolkit in use. ## Supported Profiles Seven built-in profiles: | Profile | Root | Layer chain | |---|---|---| | `default` | `docs/specs/` (or `specs/`) | requirements → design → plan → tasks (checkboxes) | | `kiro` | `.kiro/specs/` | requirements/bugfix → design → tasks | | `superpowers` | `docs/superpowers/plans/` | inline per dated plan file: Goal → Approach → Tasks | | `openspec` | `openspec/` | spec + proposal → design → tasks → archive | | `spec-kit` | `specs/` | constitution → spec → plan + data-model → tasks | | `bmad` | `_bmad-output/` | PRD → architecture → epics/stories → sprint-status | | `gsd` | `.planning/` | REQUIREMENTS → ROADMAP → phase PLANs → VERIFICATION | The full profile definitions — folder and file rules, naming anti-patterns, layer mappings, required artefacts — live in [`references/convention.md`](references/convention.md). Step 2 seeds a copy into the project at `<SPECS_ROOT>/meta/convention.md`; that local copy is the single source of truth for every check that follows. The rules are read from it, not restated here. ---