sporkwace/guv
enforces engineering-governance checks before code changes that may be unnecessary, risky, architectural, or scope-widening. use when the user asks whether to refactor, clean up, redesign, choose a next development step, review a proposed implementation, evaluate architectural consistency, review a pull request, or prevent development drift. do not use as the primary implementation skill for routine debugging, bug fixes, feature coding, or language-specific coding unless a no-op, minimal-diff, or architecture-conflict judgment is needed.
98
100%
Does it follow best practices?
Impact
96%
1.33xAverage score across 5 eval scenarios
Passed
No known issues
Quality
Discovery
100%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 strong skill description that clearly defines a governance-oriented role distinct from implementation skills. It excels in providing explicit trigger terms, clear 'use when' and 'do not use' guidance, and specific concrete actions. The negative boundary ('do not use as the primary implementation skill...') is particularly effective at reducing conflict with other coding skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists multiple specific concrete actions: enforcing engineering-governance checks, evaluating whether changes are unnecessary/risky/architectural/scope-widening, reviewing pull requests, evaluating architectural consistency, and making no-op/minimal-diff/architecture-conflict judgments. | 3 / 3 |
Completeness | Clearly answers both 'what' (enforces engineering-governance checks before code changes that may be unnecessary, risky, architectural, or scope-widening) and 'when' (explicit 'use when' clause with multiple triggers, plus a 'do not use' clause that further clarifies boundaries). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'refactor', 'clean up', 'redesign', 'next development step', 'review a proposed implementation', 'architectural consistency', 'review a pull request', 'development drift'. These are terms developers naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | The description carves out a very clear niche as a governance/gatekeeping skill distinct from implementation skills. The explicit 'do not use' clause for routine debugging, bug fixes, and feature coding significantly reduces conflict risk with coding-focused skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
100%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is an excellent governance skill that is concise, actionable, and well-structured. It provides clear decision frameworks (7-point checklist, A-D classification, architecture comparison criteria) with worked examples, all while respecting Claude's intelligence and avoiding unnecessary explanation. The progressive disclosure through referenced files is well-handled with appropriate fallback behavior.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It avoids explaining concepts Claude already knows (e.g., what refactoring is, how code reviews work) and instead provides direct, actionable governance rules. Every section earns its place with specific decision criteria and classifications. | 3 / 3 |
Actionability | The skill provides highly concrete guidance: a 7-point governance checklist, an A-D classification system for cleanup requests, specific criteria for when to proceed vs. no-op, and two worked examples showing exact output patterns. While there's no executable code (appropriate for a governance/decision skill), the guidance is specific and directly applicable. | 3 / 3 |
Workflow Clarity | The multi-step governance check is clearly sequenced (7 numbered steps), with an explicit validation gate ('if no material defect, risk, or benefit exists, stop'). The cleanup classification (A-D) provides a clear decision tree with explicit proceed/stop criteria. The architecture section includes a structured checklist for comparing options. | 3 / 3 |
Progressive Disclosure | The skill is well-structured with clear sections progressing from mandatory checks to specific domains (cleanup, architecture, pushback). The References section appropriately points to one-level-deep supporting files with clear descriptions of when each applies, and gracefully degrades when those files are absent. | 3 / 3 |
Total | 12 / 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.
Reviewed
Table of Contents