CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

branch-pr

Create Gentle AI pull requests with issue-first checks. Trigger: creating, opening, or preparing PRs for review.

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./internal/assets/skills/branch-pr/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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.

A policy-dense, well-structured instruction skill with concrete regexes, commands, and mapping tables, and a sequenced workflow with real validation checkpoints. Its weaknesses are verbosity — re-explaining conventional commit format and cramming multi-condition rules into run-on prose — and an absence of explicit error-recovery loops in the workflow.

Suggestions

Cut the conventional commit format breakdown ("type — required", "(scope) — optional", "! — optional") and trim the 11-example list to 2-3 representative ones; keep only the project-specific type-to-label mapping, since Claude already knows conventional commit syntax.

Break the dense run-on rule sentences in Critical Rules and Commands into short bullets, one condition per bullet, to preserve the same constraints in fewer, more scannable tokens.

Add explicit error-recovery branches to the workflow (e.g., "if the linked issue lacks status:approved or a required check fails, stop and report — do not proceed to PR creation") to close the feedback-loop gap.

DimensionReasoningScore

Conciseness

Mostly efficient — the tables and rule lists carry genuinely project-specific policy — but there is unnecessary explanation of conventional commit format (the "type — required...", "(scope) — optional", "! — optional" breakdown and 11 examples re-teach a format Claude already knows), and dense run-on policy sentences like "Baseline attribution requires reproducing the same failing command/environment on a comparable isolated clean base..." could be tightened into bullets. It is not a 4 because multiple sections (commit format explanation, full example list, 11-row branch table) could be trimmed; it is not a 2 because most content is novel policy, not padding or known-concept explanation.

3 / 5

Actionability

Concrete, executable guidance dominates: exact regexes for branch names and commit messages, precise commands ("go test ./...", "go run ./internal/gofmtcheck", "cd e2e && ./docker-test.sh"), and complete type-to-label mapping tables. It falls short of fully copy-paste-ready because the actual branch/PR creation commands are deliberately absent ("Do not assume main or execute branch/remote mutations from examples") and the PR body section is explicitly schematic placeholders, leaving minor gaps the model must fill at runtime.

4 / 5

Workflow Clarity

The 6-step workflow is clearly sequenced with most checkpoints present: verify "status:approved" before proceeding, "run applicable local checks and report failures honestly", "mark checkboxes only after readback", and "Read target policy and status to identify REQUIRED checks; do not infer requiredness from a pending optional run", plus a contributor checklist and automated-checks table. It is not a 5 because error-recovery feedback loops (what to do when a check fails or the issue lacks approval) are implicit rather than explicit validate→fix→retry steps.

4 / 5

Progressive Disclosure

The ~190-line single-file body has good section structure (When to Use, Critical Rules, Workflow, Branch Naming, PR Body Format, Automated Checks, Conventional Commits, Commands) with clearly signaled one-level-deep pointers to repo files (CONTRIBUTING.md, internal/assets/skills/issue-creation/SKILL.md, .github/PULL_REQUEST_TEMPLATE.md). It is not a 5 because there is no bundle at all: reference material like the commit example list and type-mapping tables sits inline in one long file, and the under-50-lines exception does not apply.

4 / 5

Total

15

/

20

Passed

Description

78%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.

A strong description with an explicit trigger clause and clear what/when structure. Its main weakness is specificity: "issue-first checks" gestures at the skill's actual behaviors (linking approved issues, exactly one type label, conventional commits) without naming them, and a few natural trigger synonyms are missing.

Suggestions

Name 1-2 of the concrete checks in the description (e.g., "link an approved base-repository issue and apply exactly one type label") to raise specificity from naming the domain to listing concrete actions.

Add a common trigger synonym such as the spelled-out "pull request" or "submit/draft a PR" to broaden natural trigger coverage.

DimensionReasoningScore

Specificity

The description names the domain ("Create Gentle AI pull requests") plus one qualifying action ("with issue-first checks"), which matches the anchor for 1-2 concrete actions without comprehensive coverage. It does not list several specific actions (e.g., linking approved issues, applying type labels, enforcing conventional commits), so it is not a 4; it is well above the minimal/generic level of a 2.

3 / 5

Completeness

It explicitly answers both questions: what ("Create Gentle AI pull requests with issue-first checks") and when (an explicit trigger clause with concrete phrases: "creating, opening, or preparing PRs for review"), matching the anchor for a clear what AND when with concrete trigger phrases. The explicit 'Trigger:' clause avoids the cap for missing trigger guidance.

5 / 5

Trigger Term Quality

"Trigger: creating, opening, or preparing PRs for review" provides good natural-phrase coverage users would actually say. It falls short of the 5 anchor because common synonyms and variations are missing — "pull request" spelled out, "submit", "draft PR", or "open a PR for review" — leaving a few natural terms absent.

4 / 5

Distinctiveness Conflict Risk

"Gentle AI" and "issue-first checks" carve out a mostly distinct niche, but the trigger phrases ("creating, opening, or preparing PRs") are the standard vocabulary of any PR-creation or PR-review skill, creating minor overlap risk with closely related skills. It is not a 5 because the triggers alone do not fully disambiguate from a generic PR helper.

4 / 5

Total

16

/

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

Gentleman-Programming/gentle-ai

Path

internal/assets/skills/branch-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.