Prepare PR Agent
Commit, rebase, build, and open/update a pull request — all in one step.
Step 1: Commit Changes Grouped by Done-Plans
Gather info
- List all done plans:
ls ./tmp/done-plans/
- Read each done-plan to understand what files and features it covers.
- Run
git diff and git diff --cached to see all staged and unstaged changes.
Associate changes with plans
For each changed file:
- Read the diff to understand what changed.
- Match to a done-plan by topic, referenced files, or feature area.
- Group into logical commit units — one commit per plan.
Grouping rules:
- Files related to the same done-plan go in one commit.
- Infrastructure/config supporting a plan goes with that plan's commit.
./tmp/ doc changes associated with a plan go in that plan's commit.- Unrelated changes (no matching plan) get their own commit with a descriptive message.
Create commits
For each group:
git add <specific files> — never git add . or git add -A- Review staged diff for secrets or credentials — warn the user if found.
- Commit with message:
type: short description (feat, fix, refactor, docs, chore). Under 72 chars. Imperative mood.
Conventions: Reference the plan name in the commit body if helpful. Keep subjects concise.
Step 2: Rebase Main onto Current Branch
- Fetch latest main:
git fetch origin main
- Rebase:
git rebase origin/main
- If conflicts occur:
- Read the conflicting files and the incoming vs current changes.
- If the resolution is obvious (e.g., non-overlapping additions, trivial formatting), resolve it yourself,
git add the resolved files, and git rebase --continue.
- If the resolution is ambiguous (e.g., both sides changed the same logic, semantic conflicts), show the user the conflict with context and ask them how to resolve it. Wait for their response before continuing.
- After rebase completes, verify with
git log --oneline -10 that history looks correct.
Step 3: Build and Quality Gates
Run the build and quality gates, fixing any errors:
pnpm build
pnpm lint
pnpm typecheck
For each command:
- If it passes, move on.
- If it fails, read the error output carefully:
- Fix type errors, missing imports, lint violations, and build issues.
- After fixing, re-run the failing command to confirm the fix.
- Repeat until all gates pass.
- If a fix requires non-trivial changes (architectural issues, missing dependencies), tell the user and ask how to proceed.
Commit build fixes as a separate commit: fix: resolve build errors
Step 4: Create or Update Pull Request
- Check for existing PR:
gh pr view --json number,title,body,url,state 2>/dev/null
If no PR exists — create one
gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
If PR already exists — update it
gh pr edit --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
PR Description Template
Build the PR description from the done-plans. List work in chronological order based on plan dates (the YYYY-MM-DD prefix in filenames). When updating an existing PR, append new work to the existing description — never overwrite previous entries.
## Summary
[1-3 sentence overview derived from done-plans and context.md]
## Work Completed
### 1. [Plan/Feature Name from earliest done-plan]
- Key changes and what they accomplish
### 2. [Plan/Feature Name from next done-plan]
- Key changes and what they accomplish
### 3. [Plan/Feature Name from latest done-plan]
- Key changes and what they accomplish
## Pre-Merge Testing
- [ ] [Short, specific thing to test based on the changes — e.g., "Verify new endpoint returns 200 with valid payload"]
- [ ] [Another key behavior to verify]
- [ ] [Edge case or integration point worth checking]
## Build Verification
- [x] `pnpm build` passes
- [x] `pnpm lint` passes
- [x] `pnpm typecheck` passes
Use $ARGUMENTS as the PR title if provided, otherwise derive one from the done-plans.
Step 5: Push to Remote
- Push the branch:
git push -u origin <branch> --force-with-lease
- Use
--force-with-lease since we rebased (safer than --force).
- If
--force-with-lease fails (remote has new commits not in local), tell the user and ask how to proceed.
Step 6: Summary
Present the final result:
PR ready.
Commits:
- <commit summaries>
Build: PASS
Lint: PASS
Typecheck: PASS
PR: <url>
Branch: <branch name> (rebased on main)
Done-plans included:
- <list of plan files>
1---2name: prepare-pr-23description: Commits changes grouped by done-plans, rebases main, runs build and quality gates, then creates or updates a PR. Replaces the commit command. Use when you're ready to open or update a pull request.4---56# Prepare PR Agent78Commit, rebase, build, and open/update a pull request — all in one step.910## Step 1: Commit Changes Grouped by Done-Plans1112### Gather info13141. List all done plans: `ls ./tmp/done-plans/`152. Read each done-plan to understand what files and features it covers.163. Run `git diff` and `git diff --cached` to see all staged and unstaged changes.1718### Associate changes with plans1920For each changed file:211. Read the diff to understand what changed.222. Match to a done-plan by topic, referenced files, or feature area.233. Group into logical commit units — one commit per plan.2425**Grouping rules**:26- Files related to the same done-plan go in one commit.27- Infrastructure/config supporting a plan goes with that plan's commit.28- `./tmp/` doc changes associated with a plan go in that plan's commit.29- Unrelated changes (no matching plan) get their own commit with a descriptive message.3031### Create commits3233For each group:341. `git add <specific files>` — **never** `git add .` or `git add -A`352. Review staged diff for secrets or credentials — warn the user if found.363. Commit with message: `type: short description` (feat, fix, refactor, docs, chore). Under 72 chars. Imperative mood.3738**Conventions**: Reference the plan name in the commit body if helpful. Keep subjects concise.3940## Step 2: Rebase Main onto Current Branch41421. Fetch latest main: `git fetch origin main`432. Rebase: `git rebase origin/main`443. If conflicts occur:45 - Read the conflicting files and the incoming vs current changes.46 - If the resolution is **obvious** (e.g., non-overlapping additions, trivial formatting), resolve it yourself, `git add` the resolved files, and `git rebase --continue`.47 - If the resolution is **ambiguous** (e.g., both sides changed the same logic, semantic conflicts), show the user the conflict with context and ask them how to resolve it. Wait for their response before continuing.484. After rebase completes, verify with `git log --oneline -10` that history looks correct.4950## Step 3: Build and Quality Gates5152Run the build and quality gates, fixing any errors:5354```bash55pnpm build56```5758```bash59pnpm lint60```6162```bash63pnpm typecheck64```6566For each command:671. If it **passes**, move on.682. If it **fails**, read the error output carefully:69 - Fix type errors, missing imports, lint violations, and build issues.70 - After fixing, re-run the failing command to confirm the fix.71 - Repeat until all gates pass.723. If a fix requires non-trivial changes (architectural issues, missing dependencies), tell the user and ask how to proceed.7374**Commit build fixes** as a separate commit: `fix: resolve build errors`7576## Step 4: Create or Update Pull Request77781. Check for existing PR: `gh pr view --json number,title,body,url,state 2>/dev/null`7980### If no PR exists — create one8182```bash83gh pr create --title "<title>" --body "$(cat <<'EOF'84<body>85EOF86)"87```8889### If PR already exists — update it9091```bash92gh pr edit --title "<title>" --body "$(cat <<'EOF'93<body>94EOF95)"96```9798### PR Description Template99100Build the PR description from the done-plans. List work in **chronological order** based on plan dates (the `YYYY-MM-DD` prefix in filenames). When updating an existing PR, **append** new work to the existing description — never overwrite previous entries.101102```markdown103## Summary104[1-3 sentence overview derived from done-plans and context.md]105106## Work Completed107### 1. [Plan/Feature Name from earliest done-plan]108- Key changes and what they accomplish109110### 2. [Plan/Feature Name from next done-plan]111- Key changes and what they accomplish112113### 3. [Plan/Feature Name from latest done-plan]114- Key changes and what they accomplish115116## Pre-Merge Testing117- [ ] [Short, specific thing to test based on the changes — e.g., "Verify new endpoint returns 200 with valid payload"]118- [ ] [Another key behavior to verify]119- [ ] [Edge case or integration point worth checking]120121## Build Verification122- [x] `pnpm build` passes123- [x] `pnpm lint` passes124- [x] `pnpm typecheck` passes125```126127Use `$ARGUMENTS` as the PR title if provided, otherwise derive one from the done-plans.128129## Step 5: Push to Remote1301311. Push the branch: `git push -u origin <branch> --force-with-lease`132 - Use `--force-with-lease` since we rebased (safer than `--force`).1332. If `--force-with-lease` fails (remote has new commits not in local), tell the user and ask how to proceed.134135## Step 6: Summary136137Present the final result:138139```140PR ready.141142Commits:143- <commit summaries>144145Build: PASS146Lint: PASS147Typecheck: PASS148149PR: <url>150Branch: <branch name> (rebased on main)151152Done-plans included:153- <list of plan files>154```
dcouple