CtrlK
BlogDocsLog inGet started
Tessl Logo

create-pr

Create pull requests using GitHub CLI with proper templates and formatting

36

Quality

33%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./plugins/git/skills/create-pr/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

35%

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

The skill covers the PR creation workflow but is significantly bloated with content Claude already knows (CLI installation, basic gh commands, what conventional commits are). The core workflow has gaps—particularly around how to actually populate the PR template rather than just passing the raw template file. The redundancy between sections (template usage explained twice, best practices and common mistakes overlap) further inflates token cost without adding value.

Suggestions

Remove the Prerequisites section (gh installation and auth) and the 'Additional GitHub CLI PR Commands' section—Claude already knows these commands and can look them up if needed.

Show a concrete, filled-in example of a PR description using the template structure, rather than just referencing the template file. The --body-file approach with a raw template doesn't produce a useful PR.

Consolidate 'Best Practices' and 'Common Mistakes to Avoid' into a single concise section, eliminating the redundancy between them.

Add a post-creation validation step (e.g., 'Verify with `gh pr view` that the PR was created correctly and the description renders properly').

DimensionReasoningScore

Conciseness

Significant verbosity throughout. Explains how to install gh CLI (Claude knows this), includes a redundant 'Using Templates for PR Creation' section that repeats earlier content, explains basic git concepts, and the 'Additional GitHub CLI PR Commands' section lists common commands Claude already knows. The 'Common Mistakes to Avoid' section largely restates the Best Practices section.

1 / 3

Actionability

Provides concrete bash commands and examples of PR title formats, which is good. However, the PR description creation is incomplete—it references a template file (@.github/pull_request_template.md) but never shows its contents, so Claude can't actually fill it out. The --body-file approach just passes the raw template without filling it in, which isn't correct usage.

2 / 3

Workflow Clarity

The workflow has a reasonable sequence (pre-flight checks → prepare description → create PR), and the pre-flight check for uncommitted changes is a good validation step. However, there's no validation after PR creation (e.g., verify the PR was created successfully, check the PR URL), and the relationship between using --body vs --body-file is unclear—using --body-file with the raw template file doesn't make sense as a workflow step.

2 / 3

Progressive Disclosure

References the PR template file appropriately, but inline content is bloated with sections that could be omitted or separated (installation instructions, additional CLI commands). The 'Using Templates for PR Creation' section at the end is redundant with earlier content. No bundle files are provided despite references to .github/pull_request_template.md.

2 / 3

Total

7

/

12

Passed

Description

32%

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 identifies a clear domain (GitHub pull requests via CLI) but is too brief and lacks explicit trigger guidance. It would benefit from listing more concrete actions and adding a 'Use when...' clause to help Claude distinguish this skill from other GitHub-related skills.

Suggestions

Add a 'Use when...' clause with trigger terms like 'PR', 'pull request', 'gh pr create', 'open a PR', 'submit changes for review'.

List more specific concrete actions such as 'create PRs from branches, set reviewers and labels, apply PR templates, draft pull requests'.

Include common user-facing synonyms and variations like 'PR', 'gh pr', 'code review submission' to improve trigger term coverage.

DimensionReasoningScore

Specificity

Names the domain (pull requests, GitHub CLI) and mentions some aspects (templates, formatting), but doesn't list multiple concrete actions beyond 'create pull requests'.

2 / 3

Completeness

Describes what the skill does but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also not very detailed, warranting a 1.

1 / 3

Trigger Term Quality

Includes good terms like 'pull requests', 'GitHub CLI', 'templates', but misses common variations users might say such as 'PR', 'gh pr', 'open a PR', 'merge request', or 'code review'.

2 / 3

Distinctiveness Conflict Risk

Specifying 'pull requests' and 'GitHub CLI' provides some distinctiveness, but could overlap with broader GitHub skills, git workflow skills, or code review skills without clearer boundaries.

2 / 3

Total

7

/

12

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

9

/

11

Passed

Repository
NeoLabHQ/context-engineering-kit
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.