Push approval protocol and post-push CI watching
65
57%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./dot_config/opencode/skill/push/SKILL.mdQuality
Discovery
22%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 description is too terse and abstract to be effective for skill selection. It lacks concrete actions, explicit trigger conditions, and natural user-facing keywords. Without a 'Use when...' clause and specific capability listing, Claude would struggle to reliably select this skill from a pool of related CI/CD or git skills.
Suggestions
Add specific concrete actions, e.g., 'Manages push approval workflows, monitors CI pipeline status after pushes, reports build failures, and handles approval gates before merging.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about pushing code, checking CI status, monitoring builds, approving pushes, or watching pipeline results.'
Include common keyword variations users might say: 'git push', 'CI pipeline', 'build status', 'continuous integration', 'approval gate', 'deploy check'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a vague domain ('push approval protocol' and 'post-push CI watching') but does not describe any concrete actions. There are no specific verbs or tasks listed—just abstract noun phrases. | 1 / 3 |
Completeness | The description weakly addresses 'what' (push approval and CI watching) but provides no 'when' clause or explicit trigger guidance. The lack of a 'Use when...' clause caps this at 2 per the rubric, and the 'what' is also very weak, so it scores 1. | 1 / 3 |
Trigger Term Quality | It includes some relevant keywords like 'push', 'CI', and 'approval' that users might mention, but misses common variations like 'git push', 'continuous integration', 'pipeline', 'deploy', 'merge', or 'build status'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'push approval protocol' and 'post-push CI watching' is somewhat specific to a CI/CD workflow niche, but the vagueness could overlap with general git skills, deployment skills, or CI configuration skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality skill with excellent actionability and workflow clarity. The push approval protocol is well-defined with clear guardrails, the CI watching loop includes proper feedback cycles, and all commands are concrete and executable. The only minor weakness is that the PR creation/CI watching sections could potentially be split out for better progressive disclosure, and the reference to the 'commit' skill should be a proper link.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section earns its place. No unnecessary explanations of git concepts, CI, or PRs. The content is dense with actionable rules and commands, with no padding or redundant context. | 3 / 3 |
Actionability | Provides specific, executable commands (git log, gh pr list, gh pr create, gh run list, gh run view) with exact flags. The two flows are clearly distinguished with concrete steps and explicit examples of what counts as approval. | 3 / 3 |
Workflow Clarity | Multi-step processes are clearly sequenced with explicit validation checkpoints. The CI watching loop has a clear feedback cycle (poll → check → fix → commit → push → repeat). The push approval protocol has explicit gates preventing unauthorized pushes. The 'What Does NOT Count as Approval' section adds important guardrails. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's moderately long and could benefit from referencing the 'commit' skill more explicitly or splitting the PR creation and CI watching into separate referenced files. The reference to 'commit skill' is mentioned but not linked. | 2 / 3 |
Total | 11 / 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.
4ed3a13
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.