pr

Use this template for writing the PR body:

## Summary

<diagram, diff-sketch, or tree>

## Evidence

<optional: one line naming the screenshots' source, viewport, and baseline>

**<view>**

| Before       | After        |
| ------------ | ------------ |
| <screenshot> | <screenshot> |

<or, when there is no real before:>

• Before: <output/failing test run> After: <output/passing test run>

Merge Danger

Door:

<optional: description>

Blast Radius:

<optional: potential ramifications of merge>

## Sections

Skip all preambles and keep prose brief. Resolve the project's domain vocabulary through /domain-modeling and use its established language.

### Summary

Pick the smallest view that makes the key point clear.

- Show logic or an algorithm as pseudocode:

```text
on(save)
  if content is unchanged
    return cached result
  write new content
  return fresh result

• Show runtime control flow as a call tree:

submitForm
  createSession
    persistPrompt
    launchAgent
  navigateToSession

• Show UI structure as a component tree, including state and module boundaries that matter:

<SessionPage> (apps/example/src/routes/session.tsx)
  useSessionEvents()
  <SessionToolbar>
    <RunSkillButton> (packages/ui)

• Show file responsibility or a broad refactor as a shallow file tree:

src/
├── commands/       # parses user actions
├── sessions/       # owns session state
└── transport/      # sends API requests

• Show component interaction, control flow, or data flow with Mermaid:

sequenceDiagram
    participant User
    participant UI
    participant Daemon
    User->>UI: choose command
    UI->>Daemon: send expanded prompt
    Daemon-->>UI: stream result

• Use diff when the point is what changes and the surrounding shape already exists. Match the diff shape to the topic.

For a component change:

 <SessionPage>
   useSessionEvents()
   <SessionToolbar>
+    <RunSkillButton />
   <SessionTimeline>
+    <SkillResultCard />

For a file-layout change:

 src/
 ├── commands/
+│   └── show-me.ts       # expands the slash command
 ├── sessions/
-└── transport.ts
+└── transport/
+    ├── client.ts
+    └── stream.ts

For a call-tree or call-stack change:

 submitForm
   createSession
     persistPrompt
+    expandSkillMention
     launchAgent
-  navigateToSession
+  navigateToSession
+    subscribeToEvents

For a state or control-flow change:

 on(save)
-  write content
+  if content is unchanged
+    return cached result
+  write new content
+  invalidate cache

• Show the whole block when most of it is new, when omitted context would hide ownership or order, or when the user needs a copyable target shape:

function expandSkill(command: string): string {
  const skillName = command.slice(1);
  return `use the ${skillName} skill`;
}

Guidance

Place each visual next to the short text it supports. Keep only the calls, files, props, states, and boundaries needed to answer the user's current question or the options to resolve the current discussion point.

You may use one of these, you may use several, it is unlikely you will use all of them. Use your judgement and don't overwhelm the user.

Evidence

Concrete evidence that the change works. Show a before and after when both exist; otherwise show the states the change adds.

Screenshots are S-tier. When the change alters what a user sees on a view and capturing it is cheap, such as a running app, a dev server with mocks, or the project's verification skill, screenshot it. Take before-and-after screenshots when the base branch shows the same view in the same state, with the same viewport, data, and scroll position, so the pair lines up. When there is no real before, such as a new view or a state the base branch never reaches (a validation error, an empty result, a new step), screenshot each state the change adds instead. A placeholder or an unrelated base-branch screen is not a before.

Show each view as a bold label, at most one sentence on what changed, and a Before | After table whose one row holds the two screenshots. Open the screenshots with one line naming their source, viewport, and baseline, such as "Mocked checkout at 1280px. Before is main, after is this branch." Show states the same way, with each state's name as its column heading, as in Empty | Not looked up: two screenshots to a row, or three for phone screenshots, with each later row's labels in the cell above it.

The project's verification skill says how to capture the base branch. Name a pair <view>-before.png and <view>-after.png, a view that is new <view>-after.png, and a state the base branch never reaches <view>--<state>.png, such as contact-step--empty.png, all in kebab case.

gh cannot attach images, so publish them on GitHub with node ~/.agents/skills/pr/scripts/pr-evidence.ts <png or directory>..., or the same script beside this skill where it is installed elsewhere, run from the PR branch's checkout. --dry-run checks the names and pushes nothing. The script commits the screenshots to pr-images/<branch>, an images-only branch that never merges, with the branch's previous commit as parent, so the images in earlier PR body revisions keep resolving. It prints the tables above, with each image linked by commit SHA.

Execution-based evidence is A-tier. Test results, console output. Show the exact test that now fails and passes, using pseudocode.

Merge Danger

Describe whether it's a one-way or two-way door. You can walk back through two-way doors, but not one-way doors. A PR that is cheap to roll back is lower risk. Changes that involve destructive actions or hard-to-reverse decisions are one-way doors.

The blast radius is the potential impact or scope of the changes introduced by this PR. Consider all possibilities. Examples are layout shift, breakages for consumers, mobile responsiveness, etc.

Complete when the description matches the final diff, shows observed evidence and limitations, and identifies merge risk. Use the invoking repository's contribution format when it overrides this default. This skill writes descriptions; publication follows the user's action grant.