Back to skills
devv1.0.0Free

Pr Description

Turn a list of changes into a clean pull-request description with Summary, Changes, Testing, and Notes for reviewers. Use when the user pastes commit titles, a diff, or bullets and asks for the PR write-up. Length matches scope; no padding, no filler.

Activate this skill on your agent
Adds pr-description to your agent’s instructions. The skill takes effect on your next provision or refresh.
Sign up to activate →
SKILL.md
# PR Description

Generate a clean, useful pull-request description from a list of changes
or a branch diff.

## When to use

Use this skill when the user:
- Pastes a list of bullets and asks for a PR description
- Pastes a diff or commit log and asks "write the PR for this"
- Has just finished a feature and asks "what should the PR say?"

## Inputs

One of:
- Plain bullets describing what changed
- Output of `git log main..HEAD --oneline`
- A diff (less common)

Optional context:
- Linked issue number(s)
- Reviewer hint (e.g. "infra team should look at this")

## Output format

```markdown
## Summary

<2–4 sentences describing what this PR does and why.>

## Changes

- <change 1 in user-visible terms>
- <change 2>
- <change 3>

## Testing

- <test 1: what was verified, how>
- <test 2>

## Notes for reviewers

- <anything non-obvious, tradeoffs, follow-ups>

Closes #<issue> _(if any)_
```

## Process

1. Cluster the bullets into "what changed at the user-visible / API level".
   Group related changes (e.g. "added X" + "wired X into navbar" = one bullet).
2. Write the **Summary** — answer "what does this PR do?" in user-facing terms,
   not implementation. The reviewer should know whether to load it after one
   read.
3. **Changes** — each bullet is a discrete, verifiable change. Reference paths
   when helpful: `Added rate limit to lib/api/auth-helpers.ts`.
4. **Testing** — what tests were added, what was manually verified. If nothing
   was tested, say so honestly.
5. **Notes for reviewers** — flag tradeoffs, deferred work, things you considered
   and rejected. This is the most valuable section.
6. Close out with `Closes #N` if an issue was referenced.

## Examples

**Input bullets:**
- added skill import API
- accepts paste, url, github
- 30/hour rate limit
- new schema columns
- 12 tests

**Output:**
```markdown
## Summary

Adds the `POST /api/skills/import` endpoint so users can drop in a SKILL.md
from their clipboard, a public URL, or a GitHub repo. The endpoint validates
the manifest, persists it to `skill_definitions` + `skill_versions`, and
optionally activates it on the user's running agent.

## Changes

- New `POST /api/skills/import` route with three source kinds (`raw`,
  `url`, `github`)
- `skill_definitions.sha256`, `source_kind`, `source_url`,
  `version_counter` columns added (migration 0014)
- Per-user rate limit: 30 imports / hour
- New `importSkill()` parser/validator in `lib/skills/import.ts`

## Testing

- 12 new unit tests in `tests/skills/` covering parse errors, fetch
  retries, and the persistence transaction
- Manually imported a real SKILL.md from GitHub end-to-end

## Notes for reviewers

- The 256KB total / 200KB body cap is enforced in three places (route,
  parser, fetcher). Intentional belt-and-braces — drop one if you'd rather.
- GitHub source resolves to `raw.githubusercontent.com` server-side; we
  never proxy the user's IP through.

Closes #182
```

## Hard rules

- Never invent a feature that wasn't in the input.
- Never write "Various improvements and bug fixes." Be specific.
- Don't pad with empty headers. If there's no testing, omit the section.
- Length should match scope: a 1-line typo fix gets a 1-line PR description.