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`).

78

1.22x
Quality

73%

Does it follow best practices?

Impact

75%

1.22x

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

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.

DimensionReasoningScore

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.

DimensionReasoningScore

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.

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.