CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

source-command-pr

Clean up code, stage changes, and prepare a pull request

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/source-command-pr/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

61%Weight 40%Scale 1-5

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

The body is a lean, well-sequenced checklist with concrete commands for the early steps, but it stops short of the workflow's terminal actions (no commit or PR-creation commands) and provides no validation checkpoints for failure cases or the blanket "git add .". A minor heading-level inconsistency keeps structure just short of clean. Weakest areas are actionability and workflow clarity.

Suggestions

Add the missing terminal commands, e.g. `git commit -m "<type>: <description>"` and `gh pr create` with the required summary sections, so the workflow is fully executable end to end.

Insert validation checkpoints: if linting or tests fail, fix the issues and re-run before proceeding, and review `git diff HEAD` output before staging rather than blindly running `git add .`.

Fix heading levels — demote "# Pull Request Preparation Checklist" to an H2 or fold it into the "Command Template" section so the document outline is consistent — and consider trimming the conventional-commit prefix list Claude already knows.

DimensionReasoningScore

Conciseness

The body is a lean checklist with four inline commands and no padding, but the conventional-commit prefix list ("fix:", "feat:", "docs:", "refactor:", "test:", "chore:") explains a convention Claude already knows. Anchor 4 (efficient with minor over-explanation to trim); not 5 because of that list, not 3 because everything else earns its place.

4 / 5

Actionability

Concrete executable commands are given for early steps ("prettier --write .", "npm test", "git diff HEAD", "git add ."), but the culminating actions have no commands — no git commit and no gh pr create, despite "prepare a pull request" being the skill's purpose. Anchor 3 (concrete guidance but missing key details); not 4 because the missing terminal commands are central, not minor, and not 2 because four concrete commands are present.

3 / 5

Workflow Clarity

Steps 1-6 form a clear sequence (lint, test, review diff, stage, commit message, PR summary) but validation checkpoints are absent: no guidance on what to do if linting or tests fail, and "git add ." batch-stages everything without verification, which caps workflow clarity at 3 per the batch-operation guideline. Not 4 because there is no feedback loop; not 2 because the sequence itself is well defined.

3 / 5

Progressive Disclosure

The skill is ~30 lines and self-contained with no bundle files, so inlining is appropriate, but structure has a glitch: an H1 ("# Pull Request Preparation Checklist") is nested inside the body under "## Command Template", producing inconsistent heading levels. Anchor 4 (good structure with minor organization gaps); not 5 due to the heading-level issue, not 3 because the content split is appropriate for a skill this size.

4 / 5

Total

14

/

20

Passed

Description

50%Weight 40%Scale 1-5

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 names a clear domain (PR preparation) with a couple of concrete actions, but it is held back by the absence of any "when to use" trigger clause and the vagueness of "Clean up code". Trigger-term coverage lacks common synonyms like "PR" and "commit". All dimensions land at the midpoint.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to create or prepare a pull request, stage changes, or run /pr".

Include natural synonyms such as "PR", "commit", and "diff" so the description matches how users actually phrase the request.

Replace the vague "Clean up code" with concrete capabilities like "run linting, fix failing tests, and write conventional commit messages".

DimensionReasoningScore

Specificity

Names the PR-preparation domain with a couple of concrete actions ("stage changes", "prepare a pull request"), but "Clean up code" is generic and coverage is thin (no linting, testing, or commit-message actions). Fits anchor 3 (domain plus 1-2 concrete actions), not 4 because few actions are listed and one is vague, not 2 because real, domain-specific actions are named.

3 / 5

Completeness

The "what" is reasonably clear (clean up code, stage changes, prepare a PR), but there is no "when" at all — no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not 4 because the "when" is entirely absent rather than merely implicit.

3 / 5

Trigger Term Quality

"pull request" and "stage changes" are natural phrases users would say, but common variations and synonyms ("PR", "commit", "diff", "get changes ready") are absent. Anchor 3 (some relevant keywords, missing variations); not 2 since the terms are domain-relevant rather than purely generic, not 4 since synonym coverage is missing.

3 / 5

Distinctiveness Conflict Risk

"prepare a pull request" carves out a distinct niche, but "Clean up code" overlaps with code-cleanup/refactoring skills and could trigger them. Anchor 3 (somewhat specific but overlap risk remains); not 4 due to that genuine overlap, not 2 because PR preparation is a real, recognizable niche.

3 / 5

Total

12

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

tonykay/transcriber

Path

.agents/skills/source-command-pr/SKILL.md

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.