Documentation
Safe documentation-only workflow. Edit markdown files without touching application source code, configs, or infrastructure. Applies Agent(content-writer) for all writing tasks.
**⚠️ CONSTRAINT: This workflow NEVER modifies source code (*.java, *.ts, *.tsx, .py, .go), configs (.yaml, .yml, .json), infrastructure (.tf, Dockerfile, Helm), or dependency files (pom.xml, package.json, requirements.txt).
1. Define Scope
Ask the user (or extract from parent workflow):
- What documentation? (technical docs, API reference, README, PRD, design doc, ADR, release notes, UI copy)
- Action: Create new / update existing / restructure
- Target files: Which
.md files will be affected
If the request is for public-facing blog / landing / marketing content, stop and route to /content-creation. This skill is internal-only.
2. Apply Roles
| Content Type |
Primary Role |
Additional Role |
| Technical documentation |
Agent(content-writer) |
— |
| API reference |
Agent(content-writer) |
Stack-specific role for accuracy |
| PRD / acceptance criteria |
Agent(product-manager) |
— |
| Architecture / ADR |
Agent(solution-architect) |
— |
| Release notes |
Agent(content-writer) |
— |
| UI microcopy |
Agent(content-writer) |
Agent(frontend-engineer) for context |
3. Gather Context
Before writing:
- Read project's
CLAUDE.md — terminology, conventions, tech stack
- Read existing docs — understand structure, tone, terminology already in use
- Identify Diátaxis mode — Tutorial, How-to, Reference, or Explanation
- Check related code (read-only) — verify technical accuracy of claims
4. Write Content
Follow Agent(content-writer) standards:
- Diátaxis framework for documentation structure
- English only unless explicitly requested otherwise
- Progressive disclosure — overview first, details on demand
- Tested examples — all code snippets must be accurate
- Consistent terminology — match existing project conventions
5. Verify
6. Summary
## Documentation Summary
- **Type**: [technical docs / blog / API reference / release notes / etc.]
- **Content mode**: [Tutorial / How-to / Reference / Explanation]
- **Files changed**:
- [file1.md]: [created/updated — what changed]
- [file2.md]: [created/updated — what changed]
- **Role(s) applied**: [Agent(content-writer), Agent(seo-engineer) if public]
- **SEO review**: [pass / N/A for internal docs]
- **Verification**: [links valid, formatting correct, no code files modified]
- **Next steps**: [if any]
Integration
- Roles:
Agent(content-writer) (primary), Agent(product-manager) (PRDs), Agent(solution-architect) (ADRs)
- Follow-up:
/pre-commit, /create-pr
- Related:
/feature-dev (inline docs during development), /release (release notes), /docs-pack (multi-document user-facing packs), /content-creation (public-facing blog / landing / marketing — owns GEO + SEO + humanizer pipeline)
1---2name: docs3description: Use this skill when the user asks to edit internal markdown documentation and source code must stay untouched — the internal documentation workflow to edit technical docs, ADRs, PRDs, design notes, release notes, and UI microcopy without touching source code, applying the Content Writer role. For public-facing blog posts, landing pages, and marketing content use `/content-creation` (it owns the GEO/SEO/humanizer pipeline). For full multi-document user-facing packs (README + API ref + runbook + tutorial) use `/docs-pack`.4argument-hint: [documentation target or section]5---67<!-- ARCHITECTURAL NOTE: no `context: fork`. This skill spawns the Content Writer subagent (and optionally an SEO Engineer subagent) via the `Agent` tool. Subagents cannot spawn other subagents (per Anthropic docs), so this skill MUST run in the main thread to retain spawn capability. -->89# Documentation1011Safe documentation-only workflow. Edit markdown files without touching application source code, configs, or infrastructure. Applies `Agent(content-writer)` for all writing tasks.1213**⚠️ CONSTRAINT: This workflow NEVER modifies source code (*.java, *.ts, *.tsx, *.py, *.go), configs (*.yaml, *.yml, *.json), infrastructure (*.tf, Dockerfile, Helm), or dependency files (pom.xml, package.json, requirements.txt).**1415## 1. Define Scope1617Ask the user (or extract from parent workflow):1819- **What documentation?** (technical docs, API reference, README, PRD, design doc, ADR, release notes, UI copy)20- **Action**: Create new / update existing / restructure21- **Target files**: Which `.md` files will be affected2223If the request is for **public-facing blog / landing / marketing content**, stop and route to `/content-creation`. This skill is internal-only.2425## 2. Apply Roles2627| Content Type | Primary Role | Additional Role |28|---|---|---|29| Technical documentation | `Agent(content-writer)` | — |30| API reference | `Agent(content-writer)` | Stack-specific role for accuracy |31| PRD / acceptance criteria | `Agent(product-manager)` | — |32| Architecture / ADR | `Agent(solution-architect)` | — |33| Release notes | `Agent(content-writer)` | — |34| UI microcopy | `Agent(content-writer)` | `Agent(frontend-engineer)` for context |3536## 3. Gather Context3738Before writing:39401. **Read project's `CLAUDE.md`** — terminology, conventions, tech stack412. **Read existing docs** — understand structure, tone, terminology already in use423. **Identify Diátaxis mode** — Tutorial, How-to, Reference, or Explanation434. **Check related code** (read-only) — verify technical accuracy of claims4445## 4. Write Content4647Follow `Agent(content-writer)` standards:4849- **Diátaxis framework** for documentation structure50- **English only** unless explicitly requested otherwise51- **Progressive disclosure** — overview first, details on demand52- **Tested examples** — all code snippets must be accurate53- **Consistent terminology** — match existing project conventions5455## 5. Verify5657- [ ] All internal links are valid (no broken references)58- [ ] Code examples are accurate and match current implementation59- [ ] Terminology is consistent with project conventions60- [ ] Formatting follows existing documentation patterns61- [ ] No secrets, PII, or internal-only information leaked62- [ ] No source code, config, or infrastructure files were modified6364## 6. Summary6566```67## Documentation Summary68- **Type**: [technical docs / blog / API reference / release notes / etc.]69- **Content mode**: [Tutorial / How-to / Reference / Explanation]70- **Files changed**:71 - [file1.md]: [created/updated — what changed]72 - [file2.md]: [created/updated — what changed]73- **Role(s) applied**: [Agent(content-writer), Agent(seo-engineer) if public]74- **SEO review**: [pass / N/A for internal docs]75- **Verification**: [links valid, formatting correct, no code files modified]76- **Next steps**: [if any]77```7879## Integration8081- **Roles**: `Agent(content-writer)` (primary), `Agent(product-manager)` (PRDs), `Agent(solution-architect)` (ADRs)82- **Follow-up**: `/pre-commit`, `/create-pr`83- **Related**: `/feature-dev` (inline docs during development), `/release` (release notes), `/docs-pack` (multi-document user-facing packs), `/content-creation` (public-facing blog / landing / marketing — owns GEO + SEO + humanizer pipeline)
avav25