create-pr

1. Review test coverage
2. Check for silent failures
3. Verify code comments are accurate
4. Review any new types
5. General code review

1. Run git diff to review uncommitted changes
2. Commit them. Follow any instructions the user gave you about writing commit messages.
3. Push to origin.
4. Use git diff origin/main... to review the full PR diff
5. 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.

Note: Keep commands CI-safe and avoid interactive gh prompts. Ensure GH_TOKEN or GITHUB_TOKEN is set in CI.

1. 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

1. 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

1. 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

1. Once CI passes and the PR is approved, ask the user if they want to merge the PR.

1. If the user confirms, merge the PR:

- Use gh pr merge --squash --delete-branch to squash-merge and delete the remote branch

1. 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

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.