feat(prompts): Code Review Coach; guides a human through a large PR

### Prompt Name

Code Review Coach

### Category

Other

### Use Case

Observe two pain points:

1. Today's Code Review agents and the integrated Copilot reviews inside PRs do the review FOR us, surfacing findings and ready-to-apply suggestions. They hand back a verdict.
1. The PR UIs and git diffs also render the files to review in filesystem order (directory tree), which has nothing to do with how the concepts and theories behind the change were actually built up.

Between the two, a reviewer often lands in unfamiliar territory with no map and an overwhelming wall of diff. That's fertile ground for cognitive surrender: the automated Copilot review gets rubber-stamped and we go on about our days. Over time, this surrender compounds into a cognitive debt which quickly becomes harder to pay than any amount of technical debt.

What if instead we gave reviewers a map of how to approach the review, plus nudges on where to direct their focus? They'd get:

- An area breakdown of the change.
- A suggested order of review: foundational areas first, then what builds on them.
- How the theory of the system got built up across commits, where the author charted that narrative in granular commits.
- Pointers in the form of questions ("Take a look at X to confirm whether Y") instead of pre-chewed findings, so the reviewer does the actual thinking.

We'd suggest this map be produced once (by the author, or by an automation similar to the existing Copilot reviews), so that multiple reviewers can benefit from a single round of token consumption rather than each re-paying for the same orientation.

This is a complement to today's PR review, not a replacement: "coach the reviewer" sitting alongside "do the review." It's also kin to the Task Challenger: same instinct of questions over answers, with the human keeping the judgment.

I've got a working initial spike of the prompt:

1. Figure out the changes itself; either diff `origin/main..HEAD`, or pull the PR content if it has MCP tools for that.
2. Give me a conceptual build-up map: break the change into areas, and where it can, order them from foundational to dependent, so I can consume it a way that builds true understanding of the changes, not the way the file list happens to sort.
3. Use the git log too; if a narrative got captured in granular commits, surface the signal.
4. Reframe more thorough review output away from concrete suggestions (the way Copilot PR review does now). Instead of handing me the exact problem and fix, coach me: "Take a look at [line/file/area] to confirm whether [the impact IF that automated suggestion were correct]." Let me do the real thinking about whether it actually holds.

### Requirements

- Coach, don't solve: every observation is a question pointing at a spot and a possible consequence. Verdicts or ready-to-paste fixes are limited to objective matters like clear typos.
- Present the change as a conceptual map of the areas, building up from foundational to dependent changes, so I can approach the changes in a more meaningful order than "filesystem".
- Surface the author's commit narrative, and flag where it reinforces or diverges from the map.
- Figure out the change from git itself (`origin/main..HEAD` or equivalent), optionally enriched with PR metadata via MCP.
- Auto-detect the target branch, with me able to confirm or correct it.
- Close by reminding me the pointers are prompts for my own judgment, not findings to rubber-stamp.

No implementation file, test, or entry point is named in the issue. Start by locating existing prompt or agent conventions in hve-core and reviewing the working spike described in the issue. Done means a prompt that maps a PR conceptually, uses commit history, asks review questions rather than giving findings, detects the target branch, and closes with the judgment reminder.

Written by the indexing model from the issue text.