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
74%
Does it follow best practices?
Impact
99%
1.10xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/.curated/yeet/SKILL.mdQuality
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.'
| Dimension | Reasoning | Score |
|---|---|---|
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.
| Dimension | Reasoning | Score |
|---|---|---|
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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
b0401f0
Table of Contents
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.