About developer-docs-editing-review
A skill for reviewing or editing developer documentation once a draft exists. It uses separate checks for accuracy, completeness, structure, clarity, and brevity, with extra verification guidance for high-risk technical content.
Key features
- 01Reviews technical accuracy and completeness
- 02Checks structure, clarity, and brevity
- 03Provides workflows for editing and verification
- 04Prioritizes findings by reader risk
- 05Routes unresolved details for review
Use cases
- 01Reviewing an existing developer guide
- 02Verifying production or migration procedures
- 03Editing documentation before release
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/developer-docs-editing-reviewin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
guidelines.mdreferences/core/knowledge.mdworkflows/edit-developer-doc.mdverify-technical-doc.mdDetails
From the project READMEDeveloper Docs Editing Review
Use this skill to improve developer documentation after a draft exists. It treats editing as validation and refactoring: check whether the doc is accurate, complete, structured, clear, brief, and reviewable.
This skill is derived from Docs for Developers: An Engineer's Field Guide to Technical Writing, especially Chapter 4, "Editing documentation." It is expanded with paraphrased guidance from Christopher Gales and the Splunk Documentation Team's The Product Is Docs: Writing Technical Documentation in a Product Development Group, especially Chapter 15, "Technical Editing," and Chapter 16, "Technical Verification." Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6
Quick Start
- Load
guidelines.mdto choose the smallest useful reference set. - Identify doc type, audience, source of truth, and release risk.
- Use separate passes for technical accuracy, completeness, structure, clarity, and brevity.
- Use
workflows/verify-technical-doc.mdwhen procedures, migrations, security, data, or production changes need formal verification. - Use
workflows/edit-developer-doc.mdfor a full edit. - Return findings first when the user asks for a review; return revised text when the user asks for an edit.
Default Output
When reviewing documentation, return:
- Findings - ordered by reader risk, with file/section references when available.
- Missing validation - commands, examples, screenshots, API facts, or source claims not checked.
- Verification route - self-test, SME review, QA test, or release blocker.
- Recommended edits - exact changes or rewrites.
- Review routing - who should validate technical details.
- Residual risk - assumptions that remain after the edit.
When editing directly, return the revised doc plus a brief change summary and unresolved questions.
Contents
| Need | Start Here |
|---|---|
| Understand editing passes | references/core/knowledge.md |
| Apply review rules | references/core/knowledge.md |
| See examples of edits and feedback | references/core/knowledge.md |
| Run a full edit | workflows/edit-developer-doc.md |
| Verify risky technical docs | workflows/verify-technical-doc.md |
| Route by task | guidelines.md |
Core Posture
- Separate writing from editing; do not polish around an unverified flaw.
- Prioritize reader-impacting errors over style preferences.
- Ask for specific reviews from the right technical owners.
- Treat high-risk procedures as release-blocking until verified or explicitly accepted.
- Integrate feedback by user need, not by reviewer rank or comment volume.