--- name: create-pr description: Create or update a PR from current branch to main, watch CI, and address feedback --- The user likes the state of the code. There are $`git status --porcelain | wc -l | tr -d ' '` uncommitted changes. The current branch is $`git branch --show-current`. The target branch is origin/main. $`git rev-parse --abbrev-ref @{upstream} 2>/dev/null && echo "Upstream branch exists." || echo "There is no upstream branch yet."` **Existing PR:** $`gh pr view --json number,title,url --jq '"#\(.number): \(.title) - \(.url)"' 2>/dev/null || echo "None"` The user requested a PR. Follow these exact steps: ## Phase 1: Review the code 1. Review test coverage 2. Check for silent failures 3. Verify code comments are accurate 4. Review any new types 5. General code review ## Phase 2: Create/Update PR 6. Run `git diff` to review uncommitted changes 7. Commit them. Follow any instructions the user gave you about writing commit messages. 8. Push to origin. 9. Use `git diff origin/main...` to review the full PR diff 10. Check if a PR already exists for this branch: - **If PR exists**: - Draft/update the description in a temp file (e.g. `/tmp/pr-body.txt`). - Update the PR body using the non-deprecated script: - `./.agents/skills/create-pr/scripts/pr-body-update.sh --file /tmp/pr-body.txt` - Re-fetch the body with `gh pr view --json body --jq .body` to confirm it changed. - **If no PR exists**: Use `gh pr create --base main` to create a new PR. Keep the title under 80 characters and the description under five sentences. The PR description should summarize ALL commits in the PR, not just the latest changes. ## Phase 3: Monitor CI and Address Issues Note: Keep commands CI-safe and avoid interactive `gh` prompts. Ensure `GH_TOKEN` or `GITHUB_TOKEN` is set in CI. 11. Watch CI status and feedback using the polling script (instead of running `gh` in a loop): - Run `./.agents/skills/create-pr/scripts/poll-pr.sh --triage-on-change --exit-when-green` (polls every 30s for 10 mins). - If checks fail, use `gh pr checks` or `gh run list` to find the failing run id, then: - Fetch the failed check logs using `gh run view --log-failed` - Analyze the failure and fix the issue - Commit and push the fix - Continue polling until all checks pass 12. Check for merge conflicts: - Run `git fetch origin main && git merge origin/main` - If conflicts exist, resolve them sensibly - Commit the merge resolution and push 13. Use the polling script output to notice new reviews and comments (avoid direct polling via `gh`): - If you need a full snapshot, run `./.agents/skills/create-pr/scripts/triage-pr.sh` once. - If you need full context after the script reports a new item, fetch details once with `gh pr view --comments` or `gh api ...`. - **Address feedback**: - For bot reviews, read the review body and any inline comments carefully - Address comments that are clearly actionable (bug fixes, typos, simple improvements) - Skip comments that require design decisions or user input - For addressed feedback, commit fixes with a message referencing the review/comment ## Phase 4: Merge and Cleanup 14. Once CI passes and the PR is approved, ask the user if they want to merge the PR. 15. If the user confirms, merge the PR: - Use `gh pr merge --squash --delete-branch` to squash-merge and delete the remote branch 16. After successful merge, check if we're in a git worktree: - Run: `[ "$(git rev-parse --git-common-dir)" != "$(git rev-parse --git-dir)" ]` - **If in a worktree**: Use the ask user question tool (`request_user_input`) to ask if they want to clean up the worktree. If yes, run `wt remove --yes --force` to remove the worktree and local branch, then switch back to the main worktree. - **If not in a worktree**: Just switch back to main with `git checkout main && git pull` ## Completion Report the final PR status to the user, including: - PR URL - CI status (passed/merged) - Any unresolved review comments that need user attention - Cleanup status (worktree removed or branch switched) If any step fails in a way you cannot resolve, ask the user for help.