simple-pr
Create a simple PR from staged changes with an auto-generated commit message
50
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/simple-pr/SKILL.mdQuality
Discovery
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 conveys the core action (creating a PR with an auto-generated commit message) but is too terse and lacks explicit trigger guidance. It misses common keyword variations like 'pull request' and 'git', and the absence of a 'Use when...' clause significantly hurts its ability to be selected appropriately from a large skill set.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to create a pull request, submit staged changes, or needs an auto-generated commit message for a PR.'
Include common keyword variations such as 'pull request', 'git', 'push changes', 'open PR', and 'merge request' to improve trigger term coverage.
Expand the capability list to mention specific actions like analyzing diffs, creating branches, or pushing to remote to better distinguish this from generic commit message or git skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (PR creation) and a couple of actions (create PR, auto-generate commit message), but doesn't list comprehensive capabilities like branch management, diff analysis, or review options. | 2 / 3 |
Completeness | Describes what it does (create a PR from staged changes with auto-generated commit message) but has no explicit 'Use when...' clause or trigger guidance, which per the rubric should cap completeness at 2, and the 'what' is also fairly thin, placing this at 1. | 1 / 3 |
Trigger Term Quality | Includes natural terms like 'PR', 'staged changes', and 'commit message' which users would say, but misses common variations like 'pull request', 'git', 'push', 'branch', or 'merge request'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'PR' + 'staged changes' + 'auto-generated commit message' is somewhat distinctive, but could overlap with general git/commit message skills or broader PR management skills. | 2 / 3 |
Total | 7 / 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 solid, well-structured workflow skill with clear sequencing, validation checkpoints, and executable commands throughout. Its main weakness is minor verbosity in explanatory comments that Claude doesn't need, and the license header/check details could be extracted to a separate reference file. Overall it provides strong actionable guidance for creating a PR from staged changes.
Suggestions
Remove explanatory sentences like 'This ensures we're working from the latest code' and 'Review the staged changes to understand what the PR will contain' — Claude already understands these purposes.
Extract the pre-PR checks (license headers, clippy, fmt) and the license header template into a separate referenced file (e.g., PRE_PR_CHECKS.md) to keep the main skill focused on the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient but includes some unnecessary explanation (e.g., 'This ensures we're working from the latest code' and 'Review the staged changes to understand what the PR will contain' are things Claude already knows). The license header example is truncated with '...' which wastes tokens without being complete. Overall reasonably lean but could be tightened. | 2 / 3 |
Actionability | Provides concrete, executable commands at every step — git status, git diff --cached, git checkout -b, cargo clippy, gh pr create, etc. The branch naming convention and commit message guidance are specific and actionable. Commands are copy-paste ready with clear placeholders. | 3 / 3 |
Workflow Clarity | Clear 8-step sequence with explicit validation checkpoints: Step 1 verifies workspace state with abort conditions, Step 4 requires user confirmation before proceeding, Step 6 runs pre-PR checks with a fix-then-proceed feedback loop. The workflow handles error recovery (fix issues before proceeding) and has clear guard rails throughout. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear numbered steps and headers, but the pre-PR checks section (Step 6) with license header details could be split into a referenced file. For a skill of this length (~60 lines of substantive content), it's borderline monolithic. No bundle files are provided, so there's no external reference structure to leverage. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- quickwit-oss/quickwit
- Commit
c61244b
- 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.