Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code.
62
72%
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 ./internal/assets/skills/work-unit-commits/SKILL.mdQuality
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.
The description is concise and well-structured with an explicit trigger clause, which is a strength. The trigger terms are mostly natural and specific to the commit-planning domain, though 'implementation' is overly broad and could cause false matches. The 'what' portion could be more specific about the concrete actions performed beyond 'plan commits.'
Suggestions
Replace the broad trigger term 'implementation' with more specific terms like 'breaking up changes', 'organizing commits', or 'PR structure' to reduce conflict risk.
Expand the 'what' clause with more concrete actions, e.g., 'Organizes code changes into logical, reviewable commit units, groups related tests and docs with implementation code, and structures chained pull requests.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (commit planning) and a few actions (commit splitting, chained PRs, keeping tests and docs with code), but doesn't list multiple concrete actions in detail—'plan commits as reviewable work units' is somewhat abstract. | 2 / 3 |
Completeness | Clearly answers both 'what' (plan commits as reviewable work units) and 'when' (explicit 'Trigger:' clause listing implementation, commit splitting, chained PRs, or keeping tests and docs with code). | 3 / 3 |
Trigger Term Quality | Includes natural trigger terms users would say: 'implementation', 'commit splitting', 'chained PRs', 'keeping tests and docs with code'. These are realistic phrases a developer would use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The term 'implementation' is quite broad and could overlap with many coding/development skills. However, 'commit splitting' and 'chained PRs' are fairly distinctive. The generic 'implementation' trigger introduces some conflict risk. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid process/methodology skill that clearly communicates commit planning principles with good structure and validation checkpoints. Its main strengths are the clear workflow sequencing, the work unit checklist, and the concrete split examples table. Weaknesses include some redundancy between sections (Critical Rules vs SDD Relationship), and the actionability could be improved with more concrete automation or scripting examples beyond basic git commands.
Suggestions
Add a concrete scripted example showing how to check changed line count and decide whether to split into chained PRs (e.g., a shell snippet that counts lines and warns at thresholds).
Tighten the SDD Relationship section to avoid repeating the verification/rollback points already covered in the Work Unit Checklist and Critical Rules table.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but has some redundancy — the SDD Relationship section repeats concepts from Critical Rules, and some table entries could be tighter. The explanations don't over-explain basic concepts Claude would know, but the overall length could be trimmed without losing clarity. | 2 / 3 |
Actionability | The skill provides concrete examples (split examples table, checklist, git commands) but is primarily instructional/process-oriented rather than executable. The guidance is specific enough to follow but lacks concrete code or automation — the git commands at the end are minimal and the SDD integration references external concepts without showing exact steps. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced: the Work Unit Checklist provides explicit validation checkpoints before committing, the PR Relationship section gives a clear 4-step sequence with a size threshold trigger, and the SDD Relationship section provides decision branches based on risk levels. The feedback loop of checking line counts before PR creation is well-defined. | 3 / 3 |
Progressive Disclosure | The content is well-organized with clear sections and headers, but everything is inline in a single file. The SDD relationship details and the split examples could potentially be in separate reference files. However, with no bundle files provided and the content being under ~80 lines of substantive material, the inline approach is borderline acceptable. | 2 / 3 |
Total | 9 / 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.
3bfa934
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.