---
name: pr-from-mentor-style
description: >-
  Reads your branch diff and writes a PR description in your mentor's house
  format (Summary / What changed / Why / Testing / Risk / Reviewer focus). The
  highest-ROI skill — use it for every PR so your write-ups match team norms.
---

# Goal

Produce a PR description that reads like your team already wrote it: accurate to
the diff, in the house format, honest about testing and risk.

# Process

1. **Read the change.** `git diff <base>...HEAD` (ask for the base branch if
   unclear — often `main`/`master`/`develop`). Read enough to describe *why*,
   not just *what*.
2. **Load the house style.** Read `mentor-pr-example.md` in this skill folder —
   match its tone, section order, and length. If the user has pasted a real
   merged PR from the team, prefer that as the template.
3. **Draft each section** from the diff (template below). Pull the real test
   commands from what was actually run (e.g. the `cpp-verify` output) — don't
   invent them.
4. **Flag risk honestly.** What could break, what's not covered, what reviewers
   should look at hardest.
5. Output the description as copy-pasteable markdown.

# Output format

```
## Summary
<1–2 sentences: what this PR does and why, in plain terms>

## What changed
- <bullet per meaningful change, grouped by area/file>

## Why
<the motivation / the bug / the ticket — context a reviewer needs>

## Testing
- <exact commands run and their result — "ctest … → 42 passed">
- <what you verified manually, if anything>

## Risk
<blast radius, what's untested, rollback story — be honest>

## Reviewer focus
<the 1–3 spots where you most want careful eyes>
```

# Rules

- **Never claim a test passed that you didn't see pass.** Pull results from real
  command output; if testing was thin, say so in Testing and Risk.
- Describe the diff that exists, not the diff you wish you wrote.
- Match `mentor-pr-example.md`'s format exactly once it's filled in with a real
  team example — house style beats this template.
- Keep it tight. Reviewers skim. No filler.
- Don't paste secrets, internal hostnames, or full proprietary source into the
  description.