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

• Review test coverage

• Check for silent failures

• Verify code comments are accurate

• Review any new types

• General code review

Phase 2: Create/Update PR

• Run git diff to review uncommitted changes

• Commit them. Follow any instructions the user gave you about writing commit messages.

• Push to origin.

• Use git diff origin/main... to review the full PR diff

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

• 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 <run-id> --log-failed

• Analyze the failure and fix the issue

• Commit and push the fix

• Continue polling until all checks pass

• 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

• 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

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

If the user confirms, merge the PR:

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

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.