pr

Load the prose-style skill and write every line of the body in that style.

Use this template for writing the PR body:

## Summary

<diagram, diff-sketch, or tree>

## Evidence

- **Before:** <screenshot/output/failing test run>
  **After:** <screenshot/output/passing test run>

## Merge Danger

**Door:** <one-way or two-way>

<optional: description>

**Blast Radius:** <one-word description>

<optional: potential ramifications of merge>

## Stack

<only for a pull request in a Stack>

Sections

Skip all preambles and keep prose brief. Use the user's domain language from GLOSSARY.md.

Summary

Pick the smallest view that makes the key point clear.

• Show logic or an algorithm as pseudocode:

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.

Screenshots are S-tier - when the environment is set up for it and the change is visual.

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.

Stack

Only a pull request in a Stack has this section, and it is the last one in the body. It is a Markdown table with one row per pull request, in merge order, first to last:

## Stack

Merge first to last.

| # | Ticket | Pull request |
|---|--------|--------------|
| 0 | Grilling docs | #51 |
| 1 | #48 Ticket title | #52 |
| 2 | #49 Ticket title | #53 (this PR) |

• # is the position in the Stack. The docs pull request is 0 and appears only when the Stack has one; otherwise the first Ticket is 1.
• Ticket is the issue number and title, or the issue link when the repo keeps its issues on another host.
• Pull request is the link, or the number on the same host. The row for the pull request being written ends with (this PR).
• A pull request not yet opened has pending in its Pull request cell. Rewrite the cell when it opens.

Opening the PR

When a skill or the user asks you to open a PR for the current branch, the caller may name a base branch and the Tickets it closes. With no base named, the PR targets the default branch.

1. Check that a PR can open: origin is on GitHub or GitLab, and its CLI (gh or glab) is installed and logged in. If not, push nothing, open nothing, and say why in one line.
2. Push the branch: git push -u origin <branch>. If the push is refused, stop and report the refusal.
3. If the branch already has an open PR (gh pr list --head <branch> --state open, glab mr list --source-branch <branch>), the push updated it. Add to its body any closing line from step 4 it lacks, bring its stack table up to date with the caller's Stack, comment on it with what the push added, mark it ready when the caller says the work is complete (gh pr ready, glab mr update --ready), and go to step 5.
4. Open it: ready for review, or as a draft when the caller says the work is partial. Use gh pr create --base <base> or glab mr create --target-branch <base>, leaving the flag out when no base is named. Title it the way the repo titles its commits and write the body from the template above, with the stack table when the caller names a Stack. End it with a Closes #<n> line for each issue the caller names that lives on this code host; name an issue from anywhere else, such as a local tracker, without the keyword.

In a Stack, each pull request closes only its own Ticket. The top pull request, the last one in the Stack, also closes the Spec. The caller names the issues, so never add the Spec's number to a lower pull request. 5. Carry out any step the repo's agent instructions (AGENTS.md, CLAUDE.md) say follows a push to a PR.

Report the PR link.