CtrlK
BlogDocsLog inGet started
Tessl Logo

open-pr

Commit the current work, push the current feature branch, and open a GitHub PR filled out from the repo's PR template. Defaults the base branch to `beta`. Assumes you're already on a feature branch — it does not create branches. Use when the user says "open a PR", "create a PR", "make a PR", or asks to submit the current changes for review.

71

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

86%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 tight, executable PR-opening workflow with concrete commands at every step and sensible validation/guardrails (base-branch stop, force-with-lease, honest test-plan checkboxes). The only gap is the absence of an explicit validate-then-retry feedback loop, which keeps workflow clarity at 4.

Suggestions

Add an explicit feedback loop for `npx prettier --check` (if it fails, fix and re-check before staging) to push workflow_clarity to 5.

The base-branch default to beta is stated in the description, intro, and step 5; consolidating it to one canonical spot would slightly improve conciseness.

DimensionReasoningScore

Conciseness

Efficient, assumes Claude's competence with concrete git/gh commands and no padding explaining what a PR or commit is; minor instances of over-direction (e.g. restating the beta default twice) that could be trimmed, keeping it just below a 5.

4 / 5

Actionability

Fully executable guidance throughout — concrete commands for each stage (`npx prettier --write`, `git add <paths>`, `git push -u origin`, `gh pr create --base beta ...`), a complete commit-message footer, and a copy-paste-ready heredoc for the PR body cover the common cases.

5 / 5

Workflow Clarity

A clear five-step sequence with explicit checkpoints (assess tree, guard against base branch, skip-to-step-4 shortcuts) and a validation stance on the test-plan checklist; it lacks a full validate-then-retry feedback loop for the prettier --check or push steps, so it sits at 4 rather than 5.

4 / 5

Progressive Disclosure

Well-organized single-file skill under 50 lines with no external references needed; sections are clearly headed and one level deep, satisfying the simple-skill exception for a 5.

5 / 5

Total

18

/

20

Passed

Description

87%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, specific description that clearly states both the action set and the trigger conditions, with explicit boundary guidance distinguishing it from branch-creation skills. Minor room to tighten trigger-term synonyms, but no over-claims or fluff.

Suggestions

Consider adding the 'pull request' long-form phrasing as a trigger variant for completeness of trigger_term_quality.

The 'Assumes you're already on a feature branch' clause is second person; rephrase to third person ('Assumes a feature branch is already checked out') to fully satisfy the voice guideline.

DimensionReasoningScore

Specificity

Lists several concrete actions — 'Commit the current work, push the current feature branch, and open a GitHub PR filled out from the repo's PR template' — plus the beta base default, but branch-creation is described as an exclusion rather than a fourth action, leaving minor coverage gaps.

4 / 5

Completeness

Explicitly answers both what (commit, push, open PR from template, default base to beta) and when ('Use when the user says "open a PR", "create a PR", "make a PR", or asks to submit the current changes for review'), with concrete trigger phrases.

5 / 5

Trigger Term Quality

Good coverage of natural phrases users actually say — 'open a PR', 'create a PR', 'make a PR', 'submit the current changes for review' — though it lacks common shorthand variants like 'PR to main' as a standalone trigger or 'submit a pull request'.

4 / 5

Distinctiveness Conflict Risk

Clear niche (PR opening only, no branching, beta default) with distinct trigger phrases and explicit boundary against branch creation, making conflict with fix-issue/feature skills minimal.

5 / 5

Total

18

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
analogjs/analog
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.