Minimal spec-driven documentation model for a repo's `docs/` tree — capability specs (with optional product-intent `Why` blocks and executable BDD `.feature` sidecars), ADRs, a `system.md` map, YAML frontmatter for filtering/preload, and an enforcement loop (git hooks → CI → linters) that makes rules self-defending. Use whenever creating, organizing, or maintaining project docs; deciding whether a change needs a doc/spec/ADR update; writing or reviewing capability specs, ADRs, PRDs, or BDD/Gherkin/Cucumber scenarios; adding frontmatter to docs; setting up checks that enforce architecture or documentation rules; reviewing PRs for documentation hygiene; or migrating an existing `docs/` tree into the spec/decision/system layout. Reach for this even when the user says "write up why we built this", "add a feature file", or "enforce our module boundaries" without naming docs explicitly.
2026-06-10