Editorial Review
Complete editorial pass for Outfitter documentation — covering voice, style, correctness, and completeness in a single skill.
Steps
- Load skills: Load the
outfitter-voice and outfitter-styleguide skills. If you cannot, do not proceed — report the failure.
- Identify target: $ARGUMENTS — can be:
- A file path (
README.md, docs/ARCHITECTURE.md)
- A directory (
docs/)
- A focus area (
voice, correctness, code examples)
- A specific question (
are all links valid?)
- Empty — review the most relevant doc in the current context
- Voice: Verify Outfitter voice (see
outfitter-voice skill): confident stance, agent-first framing, plain language over jargon.
- Style: Verify craft patterns (see
outfitter-styleguide skill): punch-and-flow rhythm, earned enthusiasm, strong opening and closing.
- Technical checks: Work through the verification checklist below.
- Report: Structured output per TEMPLATE.md. If the document is ready, say so briefly. If it needs work, be specific about locations and fixes.
Verification Checklist
Work through each dimension. For each item, document: PASS/FAIL + evidence.
Correctness (accuracy)
| Check |
How to Verify |
| Code examples run |
Extract and execute each example. Report errors verbatim. |
| API signatures match |
Compare documented signatures against source code. |
| Links resolve |
Check each link target exists (relative paths, anchors, URLs). |
| Technical claims accurate |
Cross-reference against implementation or authoritative source. |
| Versions current |
Verify version numbers match package.json, Cargo.toml, etc. |
Completeness (nothing missing)
| Check |
How to Verify |
| Required sections present |
Compare against applicable template (README, API ref, guide). |
| Parameters documented |
Each param has: type, purpose, constraints, default value. |
| Error scenarios covered |
Document what happens when things go wrong. |
| Edge cases addressed |
Empty inputs, nulls, boundaries, concurrent access. |
| Success and failure examples |
Show both happy path and error handling. |
Comprehensiveness (depth)
| Check |
How to Verify |
| Common use cases |
List 3-5 typical scenarios; verify each is addressed. |
| Migration paths |
Breaking changes include upgrade instructions. |
| Cross-references |
Related docs linked where helpful. |
| Agent-friendly |
Structured for AI consumption (clear headers, examples). |
| Troubleshooting |
Common issues and solutions documented. |
Output
Use the report structure in TEMPLATE.md.
1---2name: outfitter-editorial3description: Complete editorial review for Outfitter documentation — voice, style, correctness, and completeness. Use when reviewing docs, auditing before merge, or checking content quality.4---56# Editorial Review78Complete editorial pass for Outfitter documentation — covering voice, style, correctness, and completeness in a single skill.910## Steps11121. **Load skills**: Load the `outfitter-voice` and `outfitter-styleguide` skills. If you cannot, do not proceed — report the failure.132. **Identify target**: $ARGUMENTS — can be:14 - A file path (`README.md`, `docs/ARCHITECTURE.md`)15 - A directory (`docs/`)16 - A focus area (`voice`, `correctness`, `code examples`)17 - A specific question (`are all links valid?`)18 - Empty — review the most relevant doc in the current context193. **Voice**: Verify Outfitter voice (see `outfitter-voice` skill): confident stance, agent-first framing, plain language over jargon.204. **Style**: Verify craft patterns (see `outfitter-styleguide` skill): punch-and-flow rhythm, earned enthusiasm, strong opening and closing.215. **Technical checks**: Work through the verification checklist below.226. **Report**: Structured output per [TEMPLATE.md](TEMPLATE.md). If the document is ready, say so briefly. If it needs work, be specific about locations and fixes.2324## Verification Checklist2526Work through each dimension. For each item, document: PASS/FAIL + evidence.2728### Correctness (accuracy)2930| Check | How to Verify |31| ------------------------- | --------------------------------------------------------------- |32| Code examples run | Extract and execute each example. Report errors verbatim. |33| API signatures match | Compare documented signatures against source code. |34| Links resolve | Check each link target exists (relative paths, anchors, URLs). |35| Technical claims accurate | Cross-reference against implementation or authoritative source. |36| Versions current | Verify version numbers match package.json, Cargo.toml, etc. |3738### Completeness (nothing missing)3940| Check | How to Verify |41| ---------------------------- | ------------------------------------------------------------- |42| Required sections present | Compare against applicable template (README, API ref, guide). |43| Parameters documented | Each param has: type, purpose, constraints, default value. |44| Error scenarios covered | Document what happens when things go wrong. |45| Edge cases addressed | Empty inputs, nulls, boundaries, concurrent access. |46| Success and failure examples | Show both happy path and error handling. |4748### Comprehensiveness (depth)4950| Check | How to Verify |51| ---------------- | -------------------------------------------------------- |52| Common use cases | List 3-5 typical scenarios; verify each is addressed. |53| Migration paths | Breaking changes include upgrade instructions. |54| Cross-references | Related docs linked where helpful. |55| Agent-friendly | Structured for AI consumption (clear headers, examples). |56| Troubleshooting | Common issues and solutions documented. |5758## Output5960Use the report structure in [TEMPLATE.md](TEMPLATE.md).
outfitter-dev