CtrlK
BlogDocsLog inGet started
Tessl Logo

yeet

Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).

83

1.10x
Quality

74%

Does it follow best practices?

Impact

99%

1.10x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/.curated/yeet/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Discovery

72%

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 excels at defining a clear, narrow trigger condition with good natural keywords and strong distinctiveness. However, it conflates the 'what' and 'when' into a single trigger clause, lacking an explicit statement of what the skill does (e.g., 'Automates the full git workflow from staging changes to opening a GitHub PR'). The description is functional but reads more as a guard condition than a complete skill description.

Suggestions

Add an explicit 'what it does' clause before the trigger, e.g., 'Automates the full git-to-PR workflow: stages changes, creates a commit, pushes to a remote branch, and opens a GitHub pull request using the GitHub CLI (`gh`).'

Separate the capability description from the trigger condition so both 'what' and 'when' are independently clear, e.g., append 'Use when the user asks to stage, commit, push, and open a PR in one step.'

DimensionReasoningScore

Specificity

The description names the domain (GitHub CLI workflow) and lists actions (stage, commit, push, open a PR), but it reads more like a trigger condition than a capability description. It doesn't elaborate on what the skill actually does beyond naming the steps.

2 / 3

Completeness

The 'when' is explicitly and clearly stated ('Use only when the user explicitly asks to...'), but the 'what does this do' is only implied through the trigger condition rather than stated as a capability description. The what and when are conflated into a single clause.

2 / 3

Trigger Term Quality

Includes strong natural trigger terms: 'stage', 'commit', 'push', 'pull request', 'GitHub CLI', 'gh'. These are terms users would naturally use when requesting this workflow.

3 / 3

Distinctiveness Conflict Risk

Very specific niche: the combined flow of stage+commit+push+PR using GitHub CLI. The 'in one flow' qualifier and mention of `gh` CLI make it clearly distinguishable from general git skills or individual git operation skills.

3 / 3

Total

10

/

12

Passed

Implementation

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-crafted skill with strong actionability and workflow clarity — it provides concrete, executable commands and handles edge cases (existing PRs, missing templates, auth failures) with clear branching logic. The main weaknesses are moderate verbosity in the PR body guidelines section (which explains writing principles Claude likely already understands) and the monolithic structure that could benefit from splitting reference material into separate files. Overall it's a solid, production-ready skill.

Suggestions

Trim the PR Body Contents section by removing general writing advice Claude already knows (e.g., 'Use professional Markdown', 'put code in backticks') and focus only on the domain-specific constraints unique to this workflow.

Consider extracting the PR title conventional commit format and PR body shape into a separate reference file to improve progressive disclosure and reduce the main skill's length.

DimensionReasoningScore

Conciseness

The skill is fairly detailed and mostly earns its tokens, but includes some redundancy (e.g., the PR title type examples are well-known conventional commit types Claude already knows, the PR Body Contents section is verbose with guidance Claude could infer). The PR template discovery section and workflow steps are appropriately detailed given the complexity.

2 / 3

Actionability

The skill provides specific, executable shell commands throughout (git commands, gh CLI commands with exact flags, template discovery paths). The workflow is concrete with copy-paste-ready commands including environment variables like GH_PROMPT_DISABLED=1.

3 / 3

Workflow Clarity

The multi-step workflow is clearly sequenced with explicit validation checkpoints: checking gh installation, checking auth status, running checks before push, handling push failures, checking for existing PRs before creating new ones, and template discovery with clear branching logic for different scenarios.

3 / 3

Progressive Disclosure

The content is well-structured with clear section headers, but it's a monolithic document that could benefit from splitting out the PR body guidelines or PR title conventions into separate reference files. At ~120 lines with no bundle files, the inline detail on PR body writing guidelines is substantial and could be externalized.

2 / 3

Total

10

/

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.

Repository
openai/skills
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.