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`).
78
73%
Does it follow best practices?
Impact
75%
1.22xAverage 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
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description excels at completeness and distinctiveness by clearly specifying both when to use the skill and what it does, with a narrow and well-defined scope. The trigger terms are strong and natural. The main weakness is that the 'what' portion could be slightly more detailed about the specific actions or options available within the flow, though the conciseness is appropriate for the focused scope.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names specific actions (stage, commit, push, open a GitHub pull request) and mentions the tool (GitHub CLI / `gh`), but it doesn't elaborate on what each step entails or list additional capabilities beyond the single flow. | 2 / 3 |
Completeness | Clearly answers both 'what' (stage, commit, push, and open a GitHub pull request in one flow using `gh`) and 'when' (explicitly states 'Use only when the user explicitly asks to...'). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'stage', 'commit', 'push', 'pull request', 'GitHub', 'gh', and 'GitHub CLI' — these are terms users would naturally use when requesting this workflow. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — it targets a very specific combined workflow (stage + commit + push + PR via GitHub CLI), which is unlikely to conflict with general git skills or other GitHub-related skills. The 'only when' qualifier further narrows its scope. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable end-to-end workflow for staging, committing, pushing, and opening a PR via gh CLI. Its main weaknesses are ambiguous steps (the PR body creation instruction is confusing and not copy-paste ready) and missing validation checkpoints between critical steps. The structure and conciseness are decent but could be tightened.
Suggestions
Clarify the PR body creation step—provide an executable example showing how to write the temp file (e.g., using heredoc syntax) and how it's passed to `gh pr create --body-file pr-body.md`.
Add a concrete command for 'Run checks if not already' (e.g., `make test`, `npm test`, or indicate it's project-dependent).
Add an explicit validation checkpoint after PR creation, such as `gh pr view --web` or `gh pr status`, to confirm the PR was created successfully.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient but has some redundancy—e.g., the PR description instructions are split across two bullet points and could be consolidated. The naming conventions section is lean, but some phrasing like 'Run checks if not already' is vague rather than tight. | 2 / 3 |
Actionability | Provides specific commands (git checkout, git add, gh pr create) which is good, but several steps use pseudocode-like placeholders ('{description}') without clarifying how to derive them. The 'Run checks if not already' step is vague—no concrete command given. The PR body step mentions 'run pr-body.md' which is confusing and not executable as written. | 2 / 3 |
Workflow Clarity | The workflow is sequenced logically with conditional branching (main vs current branch) and some error recovery (retry push on auth errors, rerun checks on missing deps). However, there are no explicit validation checkpoints between steps, and the PR body creation step is confusing ('run pr-body.md to avoid \n-escaped markdown' is unclear). Missing a clear verify/validate step after the PR is created. | 2 / 3 |
Progressive Disclosure | For a skill of this size (~25 lines, single workflow), the content is well-organized into clear sections (Prerequisites, Naming conventions, Workflow) with no need for external references. Structure is appropriate and easy to scan. | 3 / 3 |
Total | 9 / 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.
724cd51
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.