How do I install the Docs Manuals skill?

Run npx skillmds@latest add jh941213/docs-manuals-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Docs Manuals safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Docs Manuals?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Docs Manuals free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Docs Manuals?

jh941213 (@jh941213) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Docs Manuals by jh941213 — Agent Skill

Name: Docs Manuals
Author: jh941213

Docs Manuals

Generate user manuals (Diátaxis) and operator manuals (runbooks, deployment guide, configuration reference, incident playbook). Use when writing user manuals/guides/tutorials, operator manuals, runbooks, deployment guides, on-call/incident response docs. API specs → docs-interfaces; architecture docs → docs-architecture; docs CI pipeline → docs-ci

jh941213 29cf00f 2 files · 4.6 KB Updated Sep 17, 2026

File contents

User/Operator Manual Skill

Writes for the actual reader (end user vs operator) in their actual situation (learning vs firefighting).

Input

$ARGUMENTS

User manual — the Diátaxis quadrants

Cardinal rule: never mix two modes in one page. Classify before writing:

Quadrant	Purpose	Form	Location
Tutorial	Learning (newcomers)	A lesson that succeeds when followed. One path, no choices	`docs/manuals/tutorials/`
How-to	Solving a task ("how do I X?")	Goal-oriented steps. Prerequisites stated	`docs/manuals/how-to/`
Reference	Looking things up	Dictionary-like. Mirrors the product's structure	`docs/manuals/reference/`
Explanation	Understanding ("why is it like this?")	Background, design reasons, trade-offs	`docs/manuals/explanation/`

Trigger mapping: new feature → how-to + reference / new concept → explanation / onboarding gap → tutorial

Index at docs/manuals/README.md — navigation organized by the four quadrants.

Operator manual

Location: docs/ops/

1. Operations overview (`docs/ops/README.md`)

System topology (link/include the deployment diagram from docs-architecture)
Capacity/scaling notes, steady-state metric baselines

2. Configuration reference (`docs/ops/configuration.md`)

Every env var/flag in a table — extracted from code (.env.example, config files, process.env/os.environ grep):

Name	Type	Default	Effect	Valid values

3. Runbooks (`docs/ops/runbooks/[alert-name].md`)

Someone seeing this for the first time at 3 a.m. must be able to follow it. Template: templates/runbook.md

One file per alert: alert name/severity/user impact → diagnosis (dashboard links + paste-ready queries) → mitigation (ordered paste-ready commands + trade-off warnings per step) → root fix/follow-up → escalation path
A new alert rule ships with its runbook in the same PR. A runbook used in an incident gets updated afterward, always

4. Deployment guide (`docs/ops/deployment.md`)

Environments, pipeline description, rollout procedure, post-deploy verification (smoke check commands), rollback procedure (the most important part — paste-ready)

5. Incident playbook (`docs/ops/incident-playbook.md`)

Severity matrix, roles (incident commander/comms lead), comms templates, escalation policy, blameless postmortem template

Procedure

Determine target: user docs vs ops docs, specific doc vs full set
Collect sources: code (config/alert rules/deploy scripts), existing docs/, CI config, docker/k8s manifests
State only facts confirmed in code — unknown operational values (dashboard URLs, on-call rotations) get  markers and a reported list
Update existing docs with Edit; Write only new ones
Update the docs/docs.yaml manifest
Prose in the project language; commands/identifiers verbatim

Constraints

Modify only docs/
Runbook commands must actually run — no nonexistent scripts/commands
One Diátaxis quadrant per page — propose a split when mixing is detected

---name: docs-manuals-2description: Generate user manuals (Diátaxis) and operator manuals (runbooks, deployment guide, configuration reference, incident playbook). Use when writing user manuals/guides/tutorials, operator manuals, runbooks, deployment guides, on-call/incident response docs. API specs → docs-interfaces; architecture docs → docs-architecture; docs CI pipeline → docs-ci---# User/Operator Manual SkillWrites for the actual reader (end user vs operator) in their actual situation (learning vs firefighting).## Input$ARGUMENTS## User manual — the Diátaxis quadrants**Cardinal rule: never mix two modes in one page.** Classify before writing:| Quadrant | Purpose | Form | Location ||----------|---------|------|----------|| Tutorial | Learning (newcomers) | A lesson that succeeds when followed. One path, no choices | `docs/manuals/tutorials/` || How-to | Solving a task ("how do I X?") | Goal-oriented steps. Prerequisites stated | `docs/manuals/how-to/` || Reference | Looking things up | Dictionary-like. Mirrors the product's structure | `docs/manuals/reference/` || Explanation | Understanding ("why is it like this?") | Background, design reasons, trade-offs | `docs/manuals/explanation/` |Trigger mapping: new feature → how-to + reference / new concept → explanation / onboarding gap → tutorialIndex at `docs/manuals/README.md` — navigation organized by the four quadrants.## Operator manualLocation: `docs/ops/`### 1. Operations overview (`docs/ops/README.md`)- System topology (link/include the deployment diagram from docs-architecture)- Capacity/scaling notes, steady-state metric baselines### 2. Configuration reference (`docs/ops/configuration.md`)Every env var/flag in a table — extracted from code (`.env.example`, config files, `process.env`/`os.environ` grep):| Name | Type | Default | Effect | Valid values ||------|------|---------|--------|--------------|### 3. Runbooks (`docs/ops/runbooks/[alert-name].md`)**Someone seeing this for the first time at 3 a.m. must be able to follow it.** Template: `templates/runbook.md`- One file per alert: alert name/severity/user impact → **diagnosis** (dashboard links + paste-ready queries) → **mitigation** (ordered paste-ready commands + trade-off warnings per step) → **root fix/follow-up** → escalation path- A new alert rule ships with its runbook in the same PR. A runbook used in an incident gets updated afterward, always### 4. Deployment guide (`docs/ops/deployment.md`)Environments, pipeline description, rollout procedure, post-deploy verification (smoke check commands), **rollback procedure** (the most important part — paste-ready)### 5. Incident playbook (`docs/ops/incident-playbook.md`)Severity matrix, roles (incident commander/comms lead), comms templates, escalation policy, blameless postmortem template## Procedure1. Determine target: user docs vs ops docs, specific doc vs full set2. Collect sources: code (config/alert rules/deploy scripts), existing docs/, CI config, docker/k8s manifests3. **State only facts confirmed in code** — unknown operational values (dashboard URLs, on-call rotations) get `` markers and a reported list4. Update existing docs with Edit; Write only new ones5. Update the `docs/docs.yaml` manifest6. Prose in the project language; commands/identifiers verbatim## Constraints- Modify only `docs/`- Runbook commands must actually run — no nonexistent scripts/commands- One Diátaxis quadrant per page — propose a split when mixing is detected

Frequently asked questions