Content
75%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A strong, highly actionable skill body with a clear workflow, explicit approval and build-verification checkpoints for a destructive batch operation, and well-signaled one-level references that all exist and deliver what they promise. Its main weakness is token duplication: the Anti-patterns section and Trigger phrases section restate content already in the reference file and frontmatter description respectively.
Suggestions
Collapse the five inline Anti-patterns to one-line NEVER summaries in the body (keeping the approval gate and build-verification rule inline) and leave the full WHY/Consequence/BAD/GOOD detail solely in references/anti-patterns.md — the two currently carry nearly identical text.
Delete or shrink the Trigger phrases section; it repeats the frontmatter description's 'Use when' clause almost verbatim and adds no new information to the loaded skill.
Integrate the build-verification step into the Workflow section as an explicit ordered checkpoint (stack → resolve conflicts → build/test → if failing, fix and re-run) so validation reads as a feedback loop rather than an aside in the anti-patterns catalog.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient (concrete commands, BAD/GOOD examples, no general git education), but roughly 40% is redundant: the ~72-line Anti-patterns section near-duplicates references/anti-patterns.md pattern-for-pattern (same five NEVERs, near-identical WHY/Consequence text), and the Trigger phrases section repeats the description's 'Use when' triggers almost verbatim. This fits anchor 3 ('mostly efficient but... could be tightened'); it is not 4 because the duplication is more than minor trimming, and not 2 because nothing is padded conceptual explanation. | 3 / 5 |
Actionability | Executable template commands appear inline ("git log <base>..<branch> --oneline --reverse", "git diff-tree --no-commit-id -r <sha> --name-only", "npm run build && npm test") alongside concrete BAD/GOOD branch names, GOOD/BAD MR description formats, and a worked proposal table; references/workflow-steps.md supplies copy-paste-ready cherry-pick sequences and worked-example.md shows fully concrete commands with real SHAs. This matches anchor 5 ('fully executable; copy-paste ready... specific examples cover the common cases'). | 5 / 5 |
Workflow Clarity | A clear seven-phase sequence (analyse → group → propose → name → stack → describe → remind) with explicit validation for this batch/destructive operation: an approval gate before any branch creation ('NEVER create branches or cherry-pick before the user approves') and a build-verification checkpoint with commands. This clears the destructive-ops cap, but sits between anchors 4 and 5: the sequence detail is delegated to the reference and the validation guidance is scattered across the Anti-patterns section rather than integrated as an ordered 'verify → fix → re-verify' loop, so 'clear sequence with most checkpoints; minor validation gaps' (4) is the best fit. | 4 / 5 |
Progressive Disclosure | Good structure: three real, one-level-deep references, each clearly signaled with a load condition ('load when executing a decomposition', 'load when explaining a failure mode', 'load when verifying output format'), and a compact inline example. However, the body's Anti-patterns section inlines the same content that references/anti-patterns.md carries, so content is not cleanly split between body and bundle — matching anchor 4's 'minor organization gaps' rather than anchor 5's 'content appropriately split'. | 4 / 5 |
Total | 16 / 20 Passed |