michi-pr-prep

The PR prep skill produces a review guide for a pull request. Not the PR description — the companion document that helps a reviewer navigate the change efficiently. It fills the gap between the author’s rich context (why decisions were made, what was tried and abandoned, where the risk lives) and the reviewer’s cold start of reading a diff.

When to use

• After completing a Michi session, before submitting the PR for review
• When reviewing someone else’s PR and wanting to produce a reading guide
• When a PR is already submitted but lacks context for reviewers
• Any time a diff is complex enough that reading it cold would miss important design decisions

What it does

The skill operates in two modes based on available context.

In-session mode (you were there). The agent has the implementation context — the transcript, decisions, tensions, and abandoned approaches. It reviews the plan doc’s Decisions and Notes sections, reconstructs the story behind the code, and drafts a guide focused on what the reviewer needs to understand before reading the diff. This is the premium output — the reviewer gets the journey, not just the destination.

From-the-diff mode (reading it cold). The agent looks at a completed PR without implementation context. It reads the file list, the diff, and the PR description, then infers design decisions from the code. It organizes files by role, flags non-obvious patterns, and gives the reviewer an efficient reading order. It is honest about what it’s inferring versus what’s evident.

Both modes produce the same structure, but depth and confidence differ.

The guide structure:

• What this PR does — brief summary of the change, what it delivers
• File map — changed files organized by role (new files, modified files, tests, config), not alphabetically, with one line per file explaining its purpose
• Design decisions worth understanding — the most valuable section. What was chosen, why, what the alternative was. In-session mode includes abandoned approaches and pivots. From-the-diff mode frames these as inferred tensions.
• Things to check during review — specific, actionable items. Not “check for bugs” but concrete instructions like “verify the error handling changes don’t break existing 422 handling.”
• What was not changed (in-session only) — explicitly scopes what the reviewer should not worry about
• Process notes (in-session only) — how the code was built, when it matters for review confidence

What it produces

• PR review guide — posted as the PR body or a companion comment. A structured document that transfers the author’s context to the reviewer.

Key things to know

• In-session mode is significantly richer than from-the-diff mode. If you ran a Michi session to build the code, use in-session mode before the context is lost.
• The guide is drafted and then presented to the human for additions. The human often has context the agent missed — especially around “what was not changed” and decisions that were made verbally.
• The “things to check” section should contain concrete, targeted review instructions. Vague guidance like “check for bugs” wastes the reviewer’s time.
• If the guide surfaces questions the agent can’t answer from context, those questions are flagged as valuable review prompts rather than answered with guesses.

For the full agent instructions, see the SKILL.md source.