CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/skill-issue-policy

The codified ticket-handling policy from 'Skill Issue' — a skill, a script, and a rule packaged as one distributable context artifact.

58

1.60x
Quality

67%

Does it follow best practices?

Impact

96%

1.60x

Average score across 1 eval scenario

SecuritybySnyk

Advisory

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a well-structured, concise workflow skill with a clear four-step process and good error handling/stop conditions. Its main weakness is that Steps 1 and 2 lack concrete commands (e.g., `gh pr create`), and the referenced script and rule have no supporting bundle files. The workflow clarity is strong with its explicit feedback loop and merge-blocking safeguard.

Suggestions

Add concrete commands for Steps 1 and 2, e.g., `git checkout -b fix/<ticket-id>` and `gh pr create --title '...' --body '...'` to make the full workflow copy-paste actionable.

Include the `scripts/await_review.py` script in the bundle or document its expected interface (arguments, exit codes, output format) so Claude can troubleshoot failures.

DimensionReasoningScore

Conciseness

The content is lean and efficient. Every sentence adds value — no explanation of what PRs are, what GitHub is, or how branching works. The scope boundary is stated in one sentence. Instructions are direct and assume Claude's competence.

3 / 3

Actionability

Step 3 provides a concrete command (`scripts/await_review.py <pr-number>`) with rationale, but Steps 1 and 2 are vague ('Make the code change', 'Open a pull request') with no specific commands or examples. There are no concrete git commands, no PR creation command (e.g., `gh pr create`), and no example of what a focused change looks like.

2 / 3

Workflow Clarity

The four steps are clearly sequenced with explicit dependencies (Step 2 blocked by tests rule, Step 4 depends on clean review). There's a feedback loop in Step 4 (address comments → re-run Step 3 → check again) and a clear stop condition ('stop and report — do not force the merge'). The validation checkpoint is well-defined.

3 / 3

Progressive Disclosure

The skill references `scripts/await_review.py` and a `tests-before-pr` rule but no bundle files are provided to support these references. The content is well-organized with clear sections, but the lack of supporting files or links to them means the references are unverifiable and potentially dead ends for Claude.

2 / 3

Total

10

/

12

Passed

Description

40%

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 focuses heavily on when to use (and not use) the skill but almost entirely neglects describing what the skill actually does. It lacks concrete actions and relies on project-specific terminology ('CODE ticket', 'context-artifact changes') that may not match natural user language. The exclusion clauses add some distinctiveness but cannot compensate for the missing capability details.

Suggestions

Add specific concrete actions the skill performs, e.g., 'Creates feature branches, implements code changes, opens pull requests, and manages the review-and-merge workflow for application source code.'

Include natural trigger terms users would say, such as 'fix bug', 'implement feature', 'pull request', 'code review', 'merge', 'PR', 'source code change'.

Restructure to clearly separate 'what' from 'when': lead with capabilities, then follow with 'Use when...' and 'Do not use when...' clauses.

DimensionReasoningScore

Specificity

The description mentions 'handling a CODE ticket' and 'review-and-merge flow' but does not list any concrete actions (e.g., create branch, write code, open PR, run tests). It describes a workflow category rather than specific capabilities.

1 / 3

Completeness

The 'when' is partially addressed ('when handling a CODE ticket... through the review-and-merge flow') and exclusions are stated, but the 'what' is essentially missing — it never explains what concrete actions the skill performs. The 'Use when' equivalent is present but the capability description is absent.

2 / 3

Trigger Term Quality

Includes some relevant terms like 'CODE ticket', 'bug', 'feature', 'review-and-merge', but these are somewhat project-specific jargon. Missing natural user phrases like 'fix a bug', 'implement feature', 'pull request', 'code review', 'merge PR'.

2 / 3

Distinctiveness Conflict Risk

The exclusions ('NOT for docs-only tickets, or for context-artifact changes') help differentiate it from related skills, but the description is still vague enough ('handling a CODE ticket') that it could overlap with other code-related skills that don't specify a review-and-merge flow.

2 / 3

Total

7

/

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.

Reviewed

Table of Contents