precommit-release-gates
How to harden pre-commit against release-only failures, especially packaging mismatches
48
52%
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 ./.squad/skills/precommit-release-gates/SKILL.mdQuality
Discovery
32%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 narrow problem domain (pre-commit hardening for release-only failures) which gives it some distinctiveness, but it reads more like a topic heading than a skill description. It lacks concrete actions, explicit trigger guidance ('Use when...'), and natural keyword variations that would help Claude reliably select this skill.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user encounters failures during releases that pass in pre-commit, or asks about hardening pre-commit hooks against packaging issues.'
List specific concrete actions the skill covers, e.g., 'Configures pre-commit hooks to validate package metadata, check version consistency, and catch packaging mismatches before release.'
Include natural trigger terms users might say, such as 'CI release failure', 'package build error', 'version mismatch', 'pyproject.toml', 'setup.cfg', or 'git hooks'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a specific domain ('pre-commit') and a general action ('harden'), and mentions 'packaging mismatches' and 'release-only failures' as specific concerns. However, it doesn't list concrete actions like 'configure hooks', 'add version checks', or 'validate package manifests'. | 2 / 3 |
Completeness | It partially addresses 'what' (hardening pre-commit against release-only failures) but has no explicit 'when' clause or trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' itself is also vague enough to warrant a score of 1. | 1 / 3 |
Trigger Term Quality | Contains some relevant keywords like 'pre-commit', 'packaging mismatches', and 'release-only failures' that a user might mention. However, it misses common variations like 'CI failures', 'build errors', 'setup.py', 'pyproject.toml', 'git hooks', or 'dependency checks'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'pre-commit' and 'release-only failures' is fairly specific and unlikely to conflict with many other skills. However, it could overlap with general CI/CD skills, pre-commit configuration skills, or packaging skills without clearer boundaries. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a concise, well-structured skill that captures hard-won lessons about release-only failures. Its main weakness is that the workflow is implicit rather than explicitly sequenced with validation checkpoints, and it could benefit from a concrete script snippet or command sequence rather than descriptive bullets. The anti-patterns section adds good guardrails.
Suggestions
Add an explicit numbered workflow (e.g., 1. Reproduce with exact release command, 2. Verify failure, 3. Add command to pre-commit script, 4. Run hook to confirm it catches the issue, 5. Update docs) with validation checkpoints.
Include a small executable code/script example, such as the relevant lines from `pre-commit.ps1` or a shell snippet showing the reproduce-and-verify cycle.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every bullet earns its place. No unnecessary explanations of what pre-commit hooks are or how packaging works. Assumes Claude understands the domain and gets straight to the novel, project-specific guidance. | 3 / 3 |
Actionability | Provides concrete patterns and real examples (specific files, specific commands like `npm run package`), but lacks executable code snippets or copy-paste-ready script fragments. The guidance is specific but still somewhat descriptive rather than fully executable. | 2 / 3 |
Workflow Clarity | The patterns section implies a sequence (reproduce → promote → sync docs → align configs) but doesn't present it as an explicit ordered workflow with validation checkpoints. For an operation that involves modifying build scripts and manifests, explicit validation steps (e.g., 'run the hook to confirm it catches the failure') would strengthen this. | 2 / 3 |
Progressive Disclosure | For a simple, focused skill under 50 lines with no need for external references, the content is well-organized into clear sections (Context, Patterns, Examples, Anti-Patterns) that are easy to scan and navigate. | 3 / 3 |
Total | 10 / 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
- sbroenne/mcp-server-excel
- Commit
e8764a6
- 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.