review-changes
Review uncommitted or recently committed documentation changes for correctness, coherence, and style compliance. Use before creating a PR to catch issues. "review my changes", "review the diff", "check the fix before submitting", "does this look right".
68
83%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly communicates both what the skill does and when to use it, with good natural trigger phrases. Its main weaknesses are moderate specificity in the capabilities listed and some potential overlap with general code review or linting skills. Adding more concrete actions and narrowing the domain slightly would strengthen it.
Suggestions
Add more specific concrete actions to improve specificity, e.g., 'checks grammar, verifies link validity, validates markdown formatting, ensures consistent terminology and tone'.
Clarify the boundary with code review skills by specifying file types or contexts, e.g., 'Use for .md, .rst, or other documentation files, not for source code review'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (documentation changes) and some actions (review for correctness, coherence, style compliance), but doesn't list multiple concrete specific actions like 'check grammar, verify links, validate formatting, ensure consistent terminology'. | 2 / 3 |
Completeness | Clearly answers both what ('Review uncommitted or recently committed documentation changes for correctness, coherence, and style compliance') and when ('Use before creating a PR to catch issues'), plus provides explicit trigger phrases. | 3 / 3 |
Trigger Term Quality | Includes natural phrases users would actually say: 'review my changes', 'review the diff', 'check the fix before submitting', 'does this look right'. Also includes contextual triggers like 'before creating a PR' and terms like 'uncommitted', 'recently committed'. | 3 / 3 |
Distinctiveness Conflict Risk | While it specifies documentation changes and diff review, it could overlap with general code review skills or style-checking skills. The scope of 'documentation changes' is somewhat broad and 'review my changes' could trigger for non-documentation reviews. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured review workflow skill with clear sequencing, concrete git commands, and specific decision criteria. Its main weakness is occasional verbosity in explanatory sentences that tell Claude things it already knows (e.g., why diffs can be misleading, why factual accuracy matters). The actionability and workflow clarity are strong, making this an effective skill overall.
Suggestions
Trim coaching/rationale sentences like 'A diff can look correct in isolation but contradict something earlier on the same page' and 'Don't assume the change is factually correct just because it reads well' — Claude already understands these concepts, and the actionable instructions that follow are sufficient.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient and well-structured, but some sections explain things Claude already knows (e.g., 'A diff can look correct in isolation but contradict something earlier on the same page', 'Don't assume the change is factually correct just because it reads well'). These coaching-style sentences add tokens without adding actionable value. | 2 / 3 |
Actionability | Provides concrete, executable git commands for each step with appropriate variants (uncommitted, last commit, branch). The decision criteria in step 7 are specific and actionable with clear approve/reject conditions and guidance on how to phrase change requests. | 3 / 3 |
Workflow Clarity | The 7-step workflow is clearly sequenced and logically ordered: identify scope → read full files → check cross-references → verify facts → evaluate readability → review code → decide. The decision step serves as a validation checkpoint with explicit criteria for approve vs request changes, and the instruction to 'quote the exact text that is wrong' provides a feedback mechanism. | 3 / 3 |
Progressive Disclosure | For a skill of this size (~80 lines) with no need for external references, the content is well-organized into clearly numbered sections with descriptive headings. No bundle files are needed, and the single-file structure is appropriate for the scope of the skill. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- docker/docs
- Commit
2ea4a02
- Reviewed
Table of Contents
Is this your skill?
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.