菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | docs-as-code-intro |
| description | 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. |
This skill is the entry-point lesson for adopting Documentation-as-Code (docs-as-code) on a real team. It is intentionally short: read it, then apply the three steps to one real document.
Treat documentation like source code.
Concretely, that means four habits:
.md file and commit it.See examples/nova-superapp/ for a complete super-app
documented end-to-end in Markdown: a single feature traced from business need (BRD) all the
way to test plan and inter-team API contract, with CODEOWNERS and a CI workflow.
CONTRIBUTING.md so contributors know the format and PR checklist.