/pr-draft — draft the PR

Final step of the AI-DLC pipeline (after the building phase). Synthesizes a pr.md from the inception artifacts and the actual work done on the branch, ready to paste into a pull request.

Input

The story slug, e.g. /pr-draft weather-tool. Reads .local/user-stories/<slug>/{story.md, design-doc.md, tasks/} where present. If the slug is omitted, infer it from the branch and the commits on it, and say which story you inferred; if that's ambiguous, list the candidates under .local/user-stories/ and ask.

Steps

1. Gather context:
   • Read story.md (scope, DoD) and design-doc.md (architecture, ADRs) if present.
   • Read tasks/README.md to see what was in scope and each task's final status.
   • Inspect the real diff: git status, git diff main...HEAD (or the appropriate base), and git log on the branch. The PR describes what actually changed, not just what was planned — reconcile the two and note any divergence.
2. Read the template in references/pr-template.md (bundled).
3. Draft pr.md:
   • Title — imperative, matches the story's intent and the repo's commit style.
   • Summary — what this PR adds/changes and why it matters, in a few sentences.
   • What's included — the concrete deliverables (files/modules/ADRs), grouped logically.
   • Testing — the exact commands a reviewer runs to verify, and what passes. Run them before writing the numbers down; never carry counts over from a previous draft or from the conversation.
   • Notes for reviewers — non-obvious decisions, intentional trade-offs, follow-ups deferred to a later story.
4. Reconcile against the DoD. Check each story Definition-of-Done checkbox against the diff — grep for the function, flag, or test that satisfies it rather than trusting the task statuses, which record intent. If any isn't met, call it out explicitly rather than implying completeness.
5. Show the draft and confirm before writing.
6. On confirmation, write .local/user-stories/<slug>/pr.md. Offer to open the PR with gh only if the user asks — do not push or create the PR unprompted. (If the user is ready to open a PR, the repo convention is to run /code-review first — remind them.)

Principles

• The PR reflects reality. If the build diverged from the design, the PR documents the as-built state and the reason, not the original plan. A divergence the reviewer would want to know about belongs in Notes, with the evidence that drove it.
• Testing steps must be copy-pasteable and verified to pass as written. ccgraph is a single binary crate: run cargo from the crate root (ccgraph/), and the full gate is fmt --check / clippy --all-targets -- -D warnings / test per CLAUDE.md.
• Keep it reviewer-oriented: what to look at, what to trust, what's deferred. Prefer a measured number over an adjective — "57 signals → 8 across 16 sessions" tells a reviewer where to look; "much less noisy" doesn't.