Claude Code skill: concise PR title/description format

concise-pr.md

name	concise-pr
description	Concise PR title/description format. Use whenever creating a pull request, writing or editing a PR description, or when asked to clean up a verbose PR body.

Concise PR format

Every PR description is exactly two sections:

## Why
The problem or motivation. Max 3 sentences.
Closes #N          <- own line, end of Why, nowhere else. Omit when there's no issue.

## What
- One verb phrase per decision. Max 5 bullets.

Don't hard-wrap lines. GitHub wraps for you, and wrapped bullets diff badly when edited.

Rules

• Why before what. Reviewers can read the diff for the "what," but they can't infer intent. If only one section survives, it's Why.
• Both caps are hard. Needing a 6th bullet means the PR is too big or the bullets are per-edit — fix that, don't raise the cap.
• One bullet per decision, not per edit. "Gate on PR author instead of github.actor" is a bullet; "updated yaml" is noise.
• A bullet carries no rationale. One verb phrase, ~12 words, no "because", "so that", or " — ". Justification belongs in Why. Fetch the classification lazily, on first reveal is a bullet; that plus "— a hidden-but-fetched value still sits in the network log" is a Why sentence wearing a bullet's clothes.
• Title does the heavy lifting: imperative mood, specific, under ~70 characters — it's what survives in git log after squash. If it needs "and", check whether it's two PRs.

Third sections

At most one section beyond Why/What, and only if it holds something a reviewer cannot derive from the diff: a measured before/after, or a deliberate divergence from the linked issue's acceptance criteria. Everything else has a better home:

• Verification, test counts → cut. verify.sh is mandatory, so "932 tests pass, 100% coverage" only reports that you followed the rules. If verification was genuinely unusual, it's one clause in Why.
• Follow-ups, "not fixed here" → file the issue, link it in one line. A PR body is not an issue tracker.
• Conflicts with another open PR → PR comment. True for a day, then it's archaeology in git log.
• Screenshots → include them when a reviewer needs to see the render, no heading otherwise.

Before creating

Reread the body and delete every clause a reviewer could infer from the diff. Do this as its own pass, not while drafting.

Example

Verbose:

What

• Switch the merge step to comment @dependabot squash and merge instead of using native auto-merge, so that Dependabot performs the merge as itself and the ruleset bypass actually applies
• Change the gate to check the PR author rather than github.actor — a human pushing to the branch was making the job skip

Verification

Workflow linted clean; watched three Dependabot PRs merge end to end.

Concise:

Title: Have Dependabot perform its own merges so the ruleset bypass applies

## Why
Green Dependabot PRs never automerged: native auto-merge waits on the required review and ignores bypass actors, and the `github.actor` gate skipped the job whenever a human updated the branch.

## What
- Merge by commenting `@dependabot squash and merge`
- Gate on PR author instead of `github.actor`
- Drop unneeded `contents: write` permission