boring-ui: Skill for Claude Code

Present PR

This is the standard final step of every implementation PR: before requesting owner validation, generate the presentation (composed context visuals + summary + sankey + importance-ordered diffs) and publish/hand the artifact to the owner.

The review flow it encodes, in the owner's own order:

1. What review already happened — was this deep-audited? thermo-reviewed? what failed and did it get fixed? Answerable yes/no without reading a single comment thread.
2. What areas/packages are touched — packages/ vs apps/ vs the rest.
3. Per-package scope check — a PR reaching into a package it has no business in is visible at a glance, with that package's ±line counts on the node.
4. Why is each file in this PR at all — one line per file or group, readable by skimming headers without opening a single diff.
5. Most important diffs first — not alphabetical, not whatever GitHub shows first.

A GitHub PR page answers none of these: it opens on a path-sorted file list with lockfiles and snapshots competing with the one file that decides the review.

When to use

• Any implementation PR that is CI-green and audited and needs a merge decision.
• A change spanning several packages, where "which seam does this touch?" comes first.

Do not use it as a substitute for the review itself. Present only what you have already reviewed, and state the open questions.

Steps

1. Understand the seam. Read the production files first and ../show-me/SKILL.md. Identify the flow the PR changes—entry point → policy/decision → effect—and compose the views that make that seam easiest to review.

2. Write the context sidecar — one markdown file, per PR, at <scratchpad>/pr-<n>-context.md:

   # PR <n> context
   
   ```text
   submitForm
     createSession
   +   expandSkillMention
       launchAgent
     navigateToSession
   ```
   
   ```ts
   type SubmitResult =
   + | { status: 'expanded'; skill: string }
     | { status: 'started'; sessionId: string }
   ```