Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →This skill should be used when creating or editing a GitHub pull request title or description, regardless of tool (gh CLI, GitHub MCP tools, API). Defines PR title format and body format with Why/What/Notes sections.
.claude/skills/fredrikaverpil-pr-style/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-08 | ✗→✓ | ▲ Improved | 22% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 91% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 31% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 5% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 46% | 0% |
Conventions for PR titles and descriptions. These apply no matter how the PR is created (gh CLI, GitHub MCP tools, API).
prose paragraphs.
faster than prose. This is desired for PRs in general, and especially for bug fixes: a minimal example of the triggering case (and what went wrong) makes the problem concrete for reviewers. Keep it short — just enough to convey the point, not a full reproduction.
no session links or model names.
Claude Code" footer to the PR body at creation time, outside your control. After creating a PR, always read it back and, if a footer was appended, update the PR body to remove it (updates are not re-footered). Also verify angle-bracket placeholders survived; the platform strips them even inside code spans.
Write the title as if the whole PR was squashed into a single commit using conventional commits. Use imperative mood (e.g., "Add feature" not "Added feature"). Keep it concise and descriptive.
markdown## Why? [Explain the motivation for this change. What problem does it solve?] ## What? [Describe what was changed. List the key modifications.] ## Notes [Optional. Additional context, testing notes, or follow-up items.]
Rules:
## Why? - Required. Explain motivation and problem being solved## What? - Required. Describe the changes made## Notes - Optional. Omit entirely if no notes are neededTry keeping Why? and What? around maximum 3 bullets each. Group related changes into one bullet rather than enumerating every file touched — reviewers read the diff for that. But keep each bullet concise and direct. Preferably only one sentence per bullet point. If it is hard to fit the PR description within these constraints, it's possible the PR is too large and discuss whether to split it up.
Use [file:lineno](url) with SHA-pinned URLs: https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>
git rev-parse HEADgit remote get-url origin (or gh repo view --jsonnameWithOwner -q .nameWithOwner when gh is available)
markdown## Why? Users need secure access to their accounts. Currently there is no authentication mechanism in place. ## What? - Add login/logout endpoints - Implement JWT token generation - Add password hashing with bcrypt - Create auth middleware for protected routes ## Notes Requires `JWT_SECRET` env variable to be set in production.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-05 | fail→fail | 5,796 | 5,927 | +2% | 1 | 1 | 0% | 940 | 1,262 | +34% | 0 | 0 | — |
case-06 | fail→fail | 8,085 | 6,953 | -14% | 1 | 1 | 0% | 1,326 | 1,146 | -14% | 0 | 0 | — |
case-01 | pass→pass | 5,815 | 31,831 | +447% | 1 | 1 | 0% | 954 | 1,198 | +26% | 0 | 0 | — |
case-02 | pass→pass | 8,615 | 4,745 | -45% | 1 | 1 | 0% | 1,374 | 1,555 | +13% | 0 | 0 | — |
case-03 | pass→pass | 7,581 | 5,252 | -31% | 1 | 1 | 0% | 1,252 | 1,712 | +37% | 0 | 0 | — |
case-04 | pass→pass | 9,871 | 5,762 | -42% | 1 | 1 | 0% | 1,534 | 1,691 | +10% | 0 | 0 | — |
case-07 | fail→fail | 7,295 | 5,881 | -19% | 1 | 1 | 0% | 1,078 | 1,144 | +6% | 0 | 0 | — |
case-08 | fail→pass | 8,970 | 6,457 | -28% | 1 | 1 | 0% | 1,542 | 1,885 | +22% | 0 | 0 | — |
case-09 | fail→pass | 5,759 | 11,402 | +98% | 1 | 1 | 0% | 1,029 | 1,966 | +91% | 0 | 0 | — |
case-10 | pass→pass | 12,729 | 4,817 | -62% | 1 | 1 | 0% | 2,047 | 1,577 | -23% | 0 | 0 | — |
case-11 | fail→pass | 6,574 | 4,015 | -39% | 1 | 1 | 0% | 1,086 | 1,421 | +31% | 0 | 0 | — |
case-12 | fail→pass | 7,997 | 3,620 | -55% | 1 | 1 | 0% | 1,339 | 1,409 | +5% | 0 | 0 | — |
case-13 | pass→pass | 6,098 | 4,938 | -19% | 1 | 1 | 0% | 1,012 | 1,592 | +57% | 0 | 0 | — |
case-14 | fail→pass | 8,106 | 5,298 | -35% | 1 | 1 | 0% | 1,199 | 1,754 | +46% | 0 | 0 | — |
case-15 | pass→pass | 5,546 | 4,428 | -20% | 1 | 1 | 0% | 1,113 | 1,703 | +53% | 0 | 0 | — |
case-16 | pass→pass | 11,412 | 3,985 | -65% | 1 | 1 | 0% | 1,747 | 1,412 | -19% | 0 | 0 | — |
case-17 | fail→pass | 3,675 | 4,270 | +16% | 1 | 1 | 0% | 594 | 1,548 | +161% | 0 | 0 | — |
case-18 | pass→pass | 5,039 | 2,797 | -44% | 1 | 1 | 0% | 802 | 1,214 | +51% | 0 | 0 | — |
case-19 | fail→pass | 13,585 | 7,954 | -41% | 1 | 1 | 0% | 2,070 | 2,192 | +6% | 0 | 0 | — |
case-20 | fail→pass | 9,953 | 6,342 | -36% | 1 | 1 | 0% | 1,594 | 1,899 | +19% | 0 | 0 | — |
case-21 | pass→pass | 8,609 | 3,304 | -62% | 1 | 1 | 0% | 1,406 | 1,369 | -3% | 0 | 0 | — |
case-22 | fail→pass | 8,296 | 7,333 | -12% | 1 | 1 | 0% | 1,415 | 2,128 | +50% | 0 | 0 | — |
case-23 | pass→pass | 7,172 | 2,644 | -63% | 1 | 1 | 0% | 1,371 | 1,244 | -9% | 0 | 0 | — |
case-24 | fail→pass | 7,893 | 6,646 | -16% | 1 | 1 | 0% | 1,390 | 1,974 | +42% | 0 | 0 | — |
case-25 | fail→fail | 7,394 | 6,057 | -18% | 1 | 1 | 0% | 1,241 | 1,822 | +47% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 25 cases were attempted, and 22 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +40 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.