OSS-docs-as-code-kit

Use when applying Documentation-as-Code across many teams or a super-app / multi-repo / monorepo with several mini-apps — how to lay out per-team docs, own API contracts at boundaries, keep one traceability matrix across teams, and run the gate per changed area. The advanced (Lesson 6) counterpart to single-project docs-as-code.

Use when wiring the docs quality gate into CI/CD — turning docs-as-code:validate into a check that blocks pull requests on a docs/frontmatter/link failure. Covers GitHub Actions, GitLab CI, and a generic shell gate, plus making CODEOWNERS enforce doc review.

Use when acting on an existing or in-progress Documentation-as-Code repo — assessing and scaffolding it, authoring or promoting a BRD/PRD/FR/NFR/ADR/Epic/Story/Test artifact, building a traceability matrix, versioning an inter-team API contract, validating frontmatter/links, auditing gaps and drift, or preparing a docs pull request. Routes the request to the right docs-as-code:* command. For a first-time conceptual introduction, defer to the docs-as-code-intro skill.

Use when measuring or reporting documentation health — explains the four docs-health metrics (coverage, freshness, contribution, contract-sync) that docs-as-code:audit reports, how each is computed, what target to hold, and how to read a declining one. For setting a docs SLO or a weekly health review.

Use when introducing a team to Documentation-as-Code — explains the principle, the minimum toolchain (Markdown + Git + PR review + CI), and the first three steps to adopt it on an existing project.