Run the full pre-push review pipeline — code review checks, self-review against CLAUDE.md, and a final report.
50
53%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/pre-push-check/SKILL.mdQuality
Discovery
57%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description identifies a specific workflow (pre-push review pipeline) and lists its components, giving it reasonable specificity and distinctiveness. However, it lacks an explicit 'Use when...' clause and could benefit from more natural trigger terms that users would actually say when they need this skill. The actions described are somewhat high-level and could be more concrete.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user is about to push code, asks for a pre-push check, or wants to review changes before pushing to a remote branch.'
Include more natural trigger terms users might say, such as 'before pushing', 'push review', 'check before push', 'git push', or 'ready to push'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (pre-push review) and lists some actions (code review checks, self-review against CLAUDE.md, final report), but the actions are somewhat vague — 'code review checks' doesn't specify what kind of checks, and 'final report' is generic. | 2 / 3 |
Completeness | Answers 'what' (run the pre-push review pipeline with code review checks, self-review, and report), but lacks an explicit 'Use when...' clause. The 'when' is only implied by the word 'pre-push'. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'pre-push', 'code review', 'CLAUDE.md', and 'review pipeline', but misses common user phrasings like 'before pushing', 'push review', 'check my code before push', or 'git push'. Users may not naturally say 'pre-push review pipeline'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'pre-push review pipeline', 'self-review against CLAUDE.md', and 'final report' creates a fairly distinct niche that is unlikely to conflict with generic code review or linting skills. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable pre-push review pipeline with clear sequencing and a useful report template. Its main weaknesses are the lack of explicit feedback loops (what happens after fixes?), the mix of concrete commands and vague review checklists, and some redundancy between steps 3 and 4. The trailing `$ARGUMENTS` placeholder suggests incomplete templating.
Suggestions
Add an explicit feedback loop: after issues are found and fixed, re-run the pipeline from step 2 before confirming ready to push.
Make steps 3 and 4 more actionable by providing concrete commands or grep patterns (e.g., `grep -rn 'console.log' src/` for detecting debug statements) rather than abstract checklists.
Remove or explain the `$ARGUMENTS` placeholder at the end — it appears to be a template artifact that adds confusion.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary elaboration. The CLAUDE.md compliance checklist items (naming conventions, architectural patterns, etc.) are somewhat verbose and could be tightened. The common issues checklist in step 4 overlaps with what step 3 already covers. However, it doesn't over-explain basic concepts. | 2 / 3 |
Actionability | Step 1 and 2 provide concrete commands (`git diff --stat`, `devflow check`), but steps 3 and 4 are review checklists without executable commands or concrete examples of how to perform the checks programmatically. The report template in step 5 is a good concrete output format, but the self-review steps are more descriptive than instructive. | 2 / 3 |
Workflow Clarity | The 6 steps are clearly sequenced and the workflow is logical (check scope → run checks → self-review → common issues → report → act on results). However, there's no explicit validation/feedback loop — if `devflow check` fails, there's no retry or fix-then-revalidate cycle. Step 6 mentions asking the user but doesn't describe what happens after fixes are applied (re-run the pipeline?). | 2 / 3 |
Progressive Disclosure | The content is reasonably well-structured with numbered steps and a report template, but it's a monolithic file with no references to external documentation. The CLAUDE.md compliance checklist and common issues list could be split into referenced files. For a skill of this length (~60 lines of substantive content), inline is borderline acceptable but the report template adds bulk. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
b0b1bb6
Table of Contents
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.