Create Pull Request Create a GitHub pull request for the current branch with an auto generated title and summary. Prerequisites Verify gh is installed and authenticated by running gh auth status . If it fails, tell the user to run gh auth login . Workflow 1. Understand the current state Run these in parallel: git status check for uncommitted changes git log oneline 20 recent commit history git rev parse abbrev ref HEAD current branch name git remote show origin grep 'HEAD branch' detect the default base branch (usually main or master ) 2. Handle uncommitted changes If there are staged or unstaged changes, ask the user whether they'd like to commit them before creating the PR. Do not commit or push without explicit approval. 3. Handle pushing Check if the current branch has a remote tracking branch and is up to date: If the branch isn't pushed or is ahead of the remote, ask the user before pushing. Push with u to set up tracking. 4. Analyze changes Most of the code in this repo is LLM generated, so reviewers lean on the PR description more than the diff. Your job here is to gather enough material to fill every section of the template in step 5 — not just enumerate what changed. Look at ALL commits on the branch, not just the latest one: While reading, deliberately collect: Why the change exists (commit messages, branch name, linked tickets) How it works at a high level (which modules/layers, data/control flow) Non obvious decisions (anything a reviewer might question) Behavioral / interface / schema changes (what's different about the system after merge) What was actually tested (look for test files added, but verify with the user / run history) Risks (breaking changes, migrations, blast radius) If you don't have material for a section, don't invent it — that section becomes N/A — <one line reason in step 5. 5. Create the PR Generate a concise title (<70 chars) describing the change at a high level. The body must follow the template below exactly . All 8 section headers must appear in order. If a section truly doesn't apply, write N/A — <one line reason under that header — never omit a header, never leave a section empty. Template (fill in under each header): Invoke with: If the base branch is not the default, pass base <branch . 6. Pre submit checklist Before running gh pr create , verify the body you assembled: [ ] All 8 section headers are present, in order: Context, Linked Issues, Design, Key Decisions, Changes, Testing, Risks & Rollout, Out of Scope / Follow ups [ ] No section is empty — each has either real content or N/A — <reason [ ] Testing lists commands that were actually run for this branch, not generic suggestions [ ] Changes describes logical/semantic differences, not a file inventory [ ] Design says how the change works at a level above the diff If anything fails, fix the body before submitting. 7. Report back Print the PR URL so the user can click through to it.

create-pr