Write a concrete, short PR body in the factory template (Summary, Why, Changes, Test evidence, Risk / rollback). Use when opening or updating a PR, running factory pr create or gh pr edit, or writing or rewriting a PR body.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Pr Description?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/volekerb-pr-description)
---
name: pr-description
description: Write a concrete, short PR body in the factory template (Summary, Why, Changes, Test evidence, Risk / rollback). Use when opening or updating a PR, running factory pr create or gh pr edit, or writing or rewriting a PR body.
---
Purpose: a reviewer should grasp the change in one minute. Write like a professional engineer: concrete, terse, checkable. Template: `.github/pull_request_template.md`. Owner request M2502.
Follow these steps in order.
1. Start from the template. Keep the template's five sections in this order: `## Summary`, `## Why`, `## Changes`, `## Test evidence`, `## Risk / rollback`. Add no other section before them.
2. Summary: 1-2 lines, what changed and the effect for the user of the code.
3. Why: the task id (T-xxxx) and one line of motivation.
4. Changes: 3-6 bullets that say what the code now does. Do not restate the diff or list files; the diff already shows them.
5. Test evidence: the exact command and its key output line, e.g. `python3 ci/affected.py --base origin/main --quick --run` -> `affected: Ran 212 tests in 9 modules: OK`. State the merged-tree test count and the origin/main count (merged >= main, rule in pre-pr-check step 4; the full count is CI's `unittest` job, read it with `gh pr checks`). For a bug fix or new guard, say the new test failed with the fix removed (coder.md C4). At load1 >= the load cap (gate_max_load_ratio x CPUs; exit 5 from the tool means the same) skip the local run and use the PR CI result instead (L-052/M16816): not a FAIL, not a blocker.
6. Risk / rollback: what could break, "rollback = revert this PR", and "applies after relaunch" when role files, plugins or settings change.
7. Keep the five sections to 150-250 words target, 300 hard limit. After Risk, add the template's `<details>` block holding the line `## Acceptance walk` (pre-pr-check) and one line per acceptance item; other long evidence (an audit table) goes in its own `<details>` block. Text inside `<details>` is outside the word count.
8. No marketing tone ("robust", "seamless", "comprehensive"), no narration of your process, no restating the task spec.
9. Add no "Generated with Claude Code" footer (owner M11175). The `Co-Authored-By` trailer belongs in the commit message, not the body.
10. Do not add a `## Gates` block. Gates belong in QA and reviewer verdicts (`factory verdict`), not in PR bodies.
11. Open a new PR with `factory pr create --title T --body -` and the full real body in a quoted heredoc, in one Bash call. Update an open PR with `gh pr edit <n> --body-file <file>`: write the file in one Bash call, then run `gh pr edit` alone in the next call (coder.md C9). Re-check the body after every push that changes the story.
Examples: docs/pr-descriptions.md.