Write or edit reader-facing technical prose for immediate comprehension. Use for documentation, PR titles and descriptions, release notes, design documents, user-facing explanations, and substantive comments. Also use when asked to make writing clearer, more natural, less AI-generated, or easier to read. For documentation fixes, handles edits, formatting, self-review, and commits after research identifies what to change. Do not use for code-only tasks with no prose deliverable.
69
86%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Follow the human-readable prose guidance in AGENTS.md and the style rules in STYLE.md. Apply the prose review below to every prose deliverable, including titles and short comments.
For a prose-only request, return the requested text after reviewing it. Use the numbered workflow for a documentation fix after research has identified what to change. Branch and commit steps apply to that workflow, not to drafting a title, description, or comment. Publishing prose requires authorization from the user.
Before returning or committing prose, read it as if explaining the change to an experienced colleague. Fix sentences that require a second reading even when their grammar is correct. Lint passing does not replace this review.
Make these edits silently. Return the requested prose without a report of this review unless the user asks for one.
git checkout -b fix/issue-<number>-<short-desc> mainUse a short kebab-case description derived from the issue title (3-5 words).
Always read each file before modifying it. Make the minimal change that fixes the issue. Do not improve surrounding content, add comments, or address adjacent problems.
Follow the writing guidelines in CLAUDE.md, STYLE.md, and COMPONENTS.md.
Every content page requires title, description, and keywords in its
front matter. If any are missing from a file you touch, add them.
rumdl runs automatically after each edit via the PostToolUse hook. Run lint manually after all edits are complete:
scripts/lint.sh <changed-markdown-files>The lint script runs rumdl and Vale on only the files you pass it, so the output is scoped to your changes. Fix errors and warnings on lines you added or changed, and review each suggestion. Vale can exit successfully when warnings or suggestions remain in its output.
Re-read each changed file: right file, right lines, change is complete,
front matter is present. Run git diff and verify only intended changes
are present. Apply the prose review to the changed text and the commit message.
Stage only the changed files:
git add <files>
git diff --cached --name-only # verify — no package-lock.json or other noise
git commit -m "$(cat <<'EOF'
docs: <short description under 72 chars> (fixes #NNNN)
<What was wrong: one sentence citing the specific problem.>
<What was changed: one sentence describing the exact edit.>
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"The commit body is mandatory. A reviewer reading only the commit should understand the problem and the fix without opening the issue.
_vendor/ or data/cli/ — these are vendoredgit log --all --full-history -- "**/filename.md"4d3cbcd
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.