Review skill
Reviews a SKILL.md file or skill directory for quality, correctness, and alignment with Claude Code skill conventions. Use when you've written a new skill and want to check it before committing, or when evaluating an existing skill for improvements.From its SKILL.md
npx -y skills add nakane1chome/claude-skills --skill review-skillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.8 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
This skill reviews and fixes other skills — identifying issues and applying corrections with developer approval at each stage.
Stop after each stage and have changes reviewed with the user.
Note: The agent checks skills against conventions and best practices, then proposes fixes. The developer approves before changes are applied. When uncertain about intent, ask — don't assume.
See
responsibilities.mdfor the full agent vs developer ownership matrix.
Each stage produces a checklist of findings (pass / issue / suggestion) and proposes fixes for any issues found. Stage 5 delivers an overall quality assessment and publish/revise/rethink recommendation.
-
Read and understand the skill (agent proposes, developer confirms)
- Read the target
SKILL.mdat$ARGUMENTS(and any supporting files in the directory). If no argument was provided, ask the user which skill to review. - Summarize: what does this skill do, when is it invoked, and what workflow does it follow?
- Confirm understanding before proceeding to review
- Read the target
-
Frontmatter review (agent reviews, then fixes with developer approval)
Check that frontmatter is well-formed and follows conventions:
- Is
namekebab-case and does it match the directory name? - Is
descriptionpresent, specific enough to trigger correctly, and does it include when-to-use context? - Are invocation control fields appropriate for the skill's purpose?
- Side-effect workflows should use
disable-model-invocation: true - Background knowledge should use
user-invocable: false
- Side-effect workflows should use
- Is
allowed-toolsset if the skill should restrict tool access? - Is
argument-hintpresent if the skill uses$ARGUMENTS? - Is the
descriptionwritten in third person? (descriptions are injected into the system prompt — third person reads naturally there) - Are
context/agentset appropriately if the skill runs in isolation? - Are there unknown or misspelled frontmatter fields?
Report findings as a checklist: pass / issue / suggestion. Then apply fixes for any issues, with developer approval.
- Is
-
Prompt structure review (agent reviews, then fixes with developer approval)
Check the prompt body for structural quality:
- Does it have a stop-after-each-stage instruction if it's a multi-stage workflow?
- Is there a Stage 0 for understanding/confirmation before doing work?
- Are agent vs developer responsibilities clear at each stage?
- Does it use questions to guide analysis, not just imperatives?
- Is the skill under 500 lines? Does it reference supporting files for detail rather than inlining everything?
- Does the skill specify what artifacts or outputs it produces and in what format? (reports, checklists, files, modified documents)
- Are file references at most one level deep from SKILL.md? (no file→file→file chains — Claude may partially read nested references)
- Is the stage numbering consistent and logical?
Report findings as a checklist: pass / issue / suggestion. Then apply fixes for any issues, with developer approval.
-
Effectiveness review (agent reviews, then fixes with developer approval)
Check that the skill will work well in practice:
- Are instructions unambiguous — will Claude interpret them correctly?
- Is the scope right-sized? (Not trying to do too much in one skill)
- Are
$ARGUMENTS,$0,$1used correctly if present? - Is dynamic context (exclamation-mark backtick syntax) used correctly if present?
- If the skill uses
$ARGUMENTS, does it handle missing or invalid arguments gracefully? (prompt the user, show usage, or fail with a clear message) - Does the skill address what happens when it encounters an error or unexpected state? (validation, recovery, or clear reporting — not every skill needs elaborate handling, but it shouldn't leave the developer guessing)
- Do reference files over 100 lines include a table of contents so Claude can see their full scope?
- Are supporting files referenced from
SKILL.md? - Check for anti-patterns:
- Overly broad or narrow description
- No review pauses in a multi-stage workflow
- Unreferenced supporting files in the directory
- Task instructions in a skill with no
context: forkand no clear action - Deeply nested file references (file→file→file chains that Claude may not follow)
- Agent escape hatches: Soft language ("where appropriate", "if you have a clear fix", "as needed") that lets the agent skip required work. Completion gates must use hard prerequisites, not discretionary phrasing. Look for: conditional qualifiers on mandatory steps, missing definitions of done, and loops without explicit exit criteria.
Report findings as a checklist: pass / issue / suggestion. Then apply fixes for any issues, with developer approval.
-
Alignment review (agent reviews, then fixes with developer approval)
If the skill is intended for this repo's skill library, check alignment with existing skills:
- Consistent formatting with other skills in the repo?
- Blockquotes for philosophy notes
- Bold for stage titles
- Tables for comparisons
- Includes "When to use this vs other skills" if it overlaps with existing skills?
- Follows the composition model (flesh-out -> review-steps -> strong-edit -> agent-optimize)?
- Has a
responsibilities.mdif it's a multi-stage workflow with mixed agent/developer ownership?
If the skill is standalone (not for this repo), skip repo-specific alignment checks and note this.
Report findings as a checklist: pass / issue / suggestion. Then apply fixes for any issues, with developer approval.
- Consistent formatting with other skills in the repo?
-
Summary and recommendations (agent leads)
Provide a final summary:
- Overall quality assessment (ready to use / needs minor fixes / needs rework)
- Top 3 issues to address (if any)
- Top 3 strengths (what the skill does well)
- Recommendation: publish / revise / rethink
- If the skill will be used across model tiers (Haiku, Sonnet, Opus), flag whether instructions are explicit enough for smaller models — what works for Opus may need more detail for Haiku
When to Use This vs Other Skills
| Goal | Use |
|---|---|
| Review a document for polish | review-steps |
| Review a document for substantive critique | strong-edit |
| Review a SKILL.md for quality and conventions | review-skill |
| Create a new skill from scratch | Start with _template, then review-skill the result |
What ships with it: 1 file
2.4 KB alongside SKILL.md
- responsibilities.md2.4 KB
Gives 0 of the 12 instructions most review quality skills give in ~1.4k tokens
Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-07
- Ask questions one at a timein 81 of 1048, across 64 files
- Provide a recommended answer for each questionin 73 of 1048, across 50 files
- Explore the codebase instead of asking answerable questionsin 66 of 1048, across 42 files
- Resolve dependencies between decisions one-by-onein 42 of 1048, across 17 files
- Interview the user relentlessly about the planin 38 of 1048, across 13 files
- Order findings by severityin 31 of 1048
- Resolve each branch of the decision treein 27 of 1048, across 5 files
- Run a grilling sessionin 26 of 1048, across 5 files
- Update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 11 files
- Propose precise canonical terms for vague languagein 25 of 1048, across 7 files
- Create documentation files lazilyin 24 of 1048, across 5 files
- Assign severity to every findingin 24 of 1048
Said here and by no other author read
- Stop after each stage for user review
- Read the target SKILL.md and supporting files
- Summarize the skill's purpose, triggers, and workflow
- Check frontmatter for correct conventions and spelling
- Check prompt body for structural quality
- Check instructions for unambiguous effectiveness
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.