ワンクリックでManusで任意のスキルを実行

docs-as-code-intro

スター2

フォーク0

更新日2026年6月2日 08:34

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 ページを確認してインストールできます。

Manusで実行

ソース

leduykhuong-daniel

leduykhuong-daniel/OSS-docs-as-code-kit

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Documentation-as-Code — Introduction

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.

The principle

Treat documentation like source code.

Concretely, that means four habits:

Plain text — write docs in Markdown, not in binary editors. Diffable, greppable, durable.
Version control — every doc change is a Git commit, with history and the ability to revert.
Review via pull request — docs changes are reviewed the same way code is.
CI/CD — pushing triggers automated checks (broken links, structure, formatting) and builds.

Why it matters

Docs stay in sync with code when they live beside it and change in the same pull request.
Contribution barrier drops — anyone can fix a typo via a PR without special tooling access.
Documentation becomes a first-class deliverable, not an afterthought.

The first three steps (apply to ONE document today)

Move it to Markdown in the repo. Pick one important doc (a runbook, an onboarding guide). Convert it to a .md file and commit it.
Open a pull request for the next change. Instead of editing in place, branch → edit → PR. Ask one teammate to review.
Add one CI check. Start with a link-checker or a Markdown linter that runs on every PR.

Worked example

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.

Where to go next

Define a CONTRIBUTING.md so contributors know the format and PR checklist.
Add a docs site generator when README-only stops scaling (the kit recommends reusing an existing Markdown/MDX site, or Starlight for a dedicated site).

このリポジトリの他の Skills

同じリポジトリ

docs-as-code-at-scale

leduykhuong-daniel/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.

2026-06-042

docs-as-code-ci-setup

leduykhuong-daniel/OSS-docs-as-code-kit

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.

2026-06-042

docs-as-code-lifecycle

leduykhuong-daniel/OSS-docs-as-code-kit

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.

2026-06-042

docs-as-code-metrics

leduykhuong-daniel/OSS-docs-as-code-kit

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.

2026-06-042

Documentation-as-Code — Introduction

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.

The principle

Treat documentation like source code.

Concretely, that means four habits:

Plain text — write docs in Markdown, not in binary editors. Diffable, greppable, durable.

Version control — every doc change is a Git commit, with history and the ability to revert.

Review via pull request — docs changes are reviewed the same way code is.

CI/CD — pushing triggers automated checks (broken links, structure, formatting) and builds.

Why it matters

Docs stay in sync with code when they live beside it and change in the same pull request.

Contribution barrier drops — anyone can fix a typo via a PR without special tooling access.

Documentation becomes a first-class deliverable, not an afterthought.

The first three steps (apply to ONE document today)

Move it to Markdown in the repo. Pick one important doc (a runbook, an onboarding guide). Convert it to a .md file and commit it.

Open a pull request for the next change. Instead of editing in place, branch → edit → PR. Ask one teammate to review.

Add one CI check. Start with a link-checker or a Markdown linter that runs on every PR.

Worked example

Where to go next

Define a CONTRIBUTING.md so contributors know the format and PR checklist.

Add a docs site generator when README-only stops scaling (the kit recommends reusing an existing Markdown/MDX site, or Starlight for a dedicated site).

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.