CtrlK
BlogDocsLog inGet started
Tessl Logo

push

Push approval protocol and post-push CI watching

65

Quality

57%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./dot_config/opencode/skill/push/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

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'.

DimensionReasoningScore

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.

DimensionReasoningScore

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
athal7/dotfiles
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.