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`.4---56<!-- 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. -->78# Documentation910Safe documentation-only workflow. Edit markdown files without touching application source code, configs, or infrastructure. Applies `Agent(content-writer)` for all writing tasks.1112**⚠️ 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).**1314## 1. Define Scope1516Ask the user (or extract from parent workflow):1718- **What documentation?** (technical docs, API reference, README, PRD, design doc, ADR, release notes, UI copy)19- **Action**: Create new / update existing / restructure20- **Target files**: Which `.md` files will be affected2122If the request is for **public-facing blog / landing / marketing content**, stop and route to `/content-creation`. This skill is internal-only.2324## 2. Apply Roles2526| Content Type | Primary Role | Additional Role |27|---|---|---|28| Technical documentation | `Agent(content-writer)` | — |29| API reference | `Agent(content-writer)` | Stack-specific role for accuracy |30| PRD / acceptance criteria | `Agent(product-manager)` | — |31| Architecture / ADR | `Agent(solution-architect)` | — |32| Release notes | `Agent(content-writer)` | — |33| UI microcopy | `Agent(content-writer)` | `Agent(frontend-engineer)` for context |3435## 3. Gather Context3637Before writing:38391. **Read project's `CLAUDE.md`** — terminology, conventions, tech stack402. **Read existing docs** — understand structure, tone, terminology already in use413. **Identify Diátaxis mode** — Tutorial, How-to, Reference, or Explanation424. **Check related code** (read-only) — verify technical accuracy of claims4344## 4. Write Content4546Follow `Agent(content-writer)` standards:4748- **Diátaxis framework** for documentation structure49- **English only** unless explicitly requested otherwise50- **Progressive disclosure** — overview first, details on demand51- **Tested examples** — all code snippets must be accurate52- **Consistent terminology** — match existing project conventions5354## 5. Verify5556- [ ] All internal links are valid (no broken references)57- [ ] Code examples are accurate and match current implementation58- [ ] Terminology is consistent with project conventions59- [ ] Formatting follows existing documentation patterns60- [ ] No secrets, PII, or internal-only information leaked61- [ ] No source code, config, or infrastructure files were modified6263## 6. Summary6465```66## Documentation Summary67- **Type**: [technical docs / blog / API reference / release notes / etc.]68- **Content mode**: [Tutorial / How-to / Reference / Explanation]69- **Files changed**:70 - [file1.md]: [created/updated — what changed]71 - [file2.md]: [created/updated — what changed]72- **Role(s) applied**: [Agent(content-writer), Agent(seo-engineer) if public]73- **SEO review**: [pass / N/A for internal docs]74- **Verification**: [links valid, formatting correct, no code files modified]75- **Next steps**: [if any]76```7778## Integration7980- **Roles**: `Agent(content-writer)` (primary), `Agent(product-manager)` (PRDs), `Agent(solution-architect)` (ADRs)81- **Follow-up**: `/pre-commit`, `/create-pr`82- **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