docs-as-code

Plugin docs-as-code from marketplace docs-as-code-kit in leduykhuong-daniel/OSS-docs-as-code-kit. Commands read from the repo's manifest — 1 month ago.

Skills (6)

• ai-agent-spec-authoring

  Use when designing an AI agent feature and you need a single architecture document that declares persona + tools + memory + autonomy + cost budget + guardrails. Produces an "Agent Spec" (the HOW) as a companion to a PRD (the WHAT/WHY). Trigger phrases: agent spec, persona spec, tool fabric design, a

• docs-as-code-at-scale

  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 t

• docs-as-code-ci-setup

  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.

• docs-as-code-intro

  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.

• docs-as-code-lifecycle

  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,

• docs-as-code-metrics

  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 revie

Slash commands (14)

• /docs-as-code:README
• /docs-as-code:audit

  Health audit of the docs — traceability gaps, documentation drift (docs older than code, contract↔code mismatch), and the four health metrics. Read-only; the one command to answer "what's wrong with our docs?".

• /docs-as-code:contract

  Create or version an inter-team API contract. `new <provider> <api>` scaffolds a versioned contract; `bump <path> [--breaking]` raises the version (breaking = new major + consumer-notification checklist).

• /docs-as-code:diagram

  Render the traceability chains as a Mermaid flowchart from product-docs frontmatter — a visual BRD→PRD→FR/NFR→Epic→Story→Test graph, with missing-but-referenced artifacts flagged. Drops straight into a Markdown doc or a docs site.

• /docs-as-code:init

  Assess the current repo for docs-as-code readiness (git, docs/, CI, templates), then scaffold the product-docs structure and a minimal CI check.

• /docs-as-code:learn

  Introduce and teach Documentation-as-Code to the user — explain the principle, walk the curriculum, and guide them to apply it to their own repo. Use when someone is new to docs-as-code or wants a guided introduction.

• /docs-as-code:migrate

  Migrate an existing legacy document (Word/PDF/Confluence export/scattered Markdown) into the product-docs structure — classify its artifact type, convert to Markdown, scaffold with frontmatter, and link it into the traceability chain.

• /docs-as-code:new

  Create a new product-docs artifact (brd|prd|fr|nfr|adr|epic|story|test) from the matching template, with frontmatter pre-filled and traceability auto-linked to its upstream artifact.

• /docs-as-code:onboard

  Onboard a team to Documentation-as-Code — assess their repo's current doc maturity, then produce a tailored adoption roadmap (which lessons, which commands first, a two-to-four-week rollout). For a team that wants to adopt docs-as-code but does not know where to start.

• /docs-as-code:promote

  Promote a doc through its lifecycle status (draft → review → active/published, or deprecate), updating the status field and date and logging the transition.

• /docs-as-code:publish

  Set up or build a static documentation site from the product-docs Markdown — wires a site generator (VitePress or MkDocs), a navigation tree from the docs structure, search, and a build step suitable for CI/Pages deploy. Docs become a browsable site without leaving Markdown.

• /docs-as-code:review

  Prepare a docs pull request — verify docs+code+(contract) changed together, assign the right reviewers (CODEOWNERS, including contract consumers), and generate a PR description (what/why/impact/migration).

• /docs-as-code:trace

  Build or verify the cross-artifact traceability matrix from frontmatter — surface gaps (a missing Test = an unverified requirement), broken ID links, and orphaned artifacts.

• /docs-as-code:validate

  Validate docs — required frontmatter fields, Markdown lint, and internal/external link checks across product-docs and contracts. Reports file:line for each issue and exits non-zero on failure (CI-ready).

Subagents (6)

• README
• contract-breaking-detector

  Inspects a change to an inter-team API contract and classifies it as breaking or non-breaking, identifies every affected consumer, and produces a migration-notification checklist. Use when a *.contract.md changes (or before merging one) to prevent the "added a required field and broke consumers" inc

• docs-reviewer

  Reviews a documentation change (a docs PR or a set of changed .md files) for docs-as-code quality — runs validate + trace + drift, checks the docs+code+contract "changed together" rule, and returns a BLOCK/FLAG/PASS verdict with evidence. Use when reviewing docs changes before merge.

• migration-planner

  Surveys an existing body of legacy documentation (a folder of Word/PDF/Confluence exports/scattered Markdown) and produces a sequenced migration plan — classifying each document by artifact type and ordering the work by traceability tier. Use before a bulk docs migration to decide what moves first;

• onboarding-coach

  Assesses a team's repo and current documentation maturity, then produces a tailored Documentation-as-Code adoption roadmap — which lessons to read, which commands to run first, and a realistic two-to-four-week rollout plan. Use when a team wants to adopt docs-as-code but does not know where to start

• traceability-auditor

  Deep-audits the traceability matrix of a product-docs repo — reconstructs every BRD→PRD→FR/NFR→Epic→Story→Test chain, scores coverage, and lists unverified requirements, dead ID links, and orphaned artifacts with evidence. Use for a release-readiness or quarterly docs audit (deeper than the per-PR d

Similar plugins