pr-complete

PR Complete

This PR is checked, reviewed, and no other tasks are left. Complete the following:

Step 0: Pre-flight — check for uncommitted changes

Before anything else, run git status and git diff --stat to check for unstaged or staged-but-uncommitted changes.

• If the working tree is clean → skip to step 1.
• If there are uncommitted changes:
  • Look at what changed. In most cases, the user simply forgot to commit before invoking /pr-complete.
  • If it's clearly work that belongs in this PR (source code, config, docs related to the current branch's topic) → invoke /commits push to commit and push automatically, then continue to step 1.
  • If it's ambiguous (unrelated files, experimental changes, files you're unsure about) → tell the user: "There are uncommitted changes. Please run /commits push first, then re-invoke /pr-complete." and stop here.

Step 1: Check PR status

1. Check the current PR status and CI checks using gh pr view and gh pr checks
2. If --no-wait / -now was passed → skip the CI wait and merge immediately (see "--no-wait (-now) option" below)
3. If all CI checks have already passed and the PR is approved → proceed to step 4
4. If CI checks are still in progress:

• Invoke /watch-ci to monitor CI in the background
• Tell the user: "CI is still running. Watching in background via /watch-ci"
• do NOT block the conversation with polling

5. Once all CI checks are green and the PR is approved:

• Merge the PR using gh pr merge --merge --delete-branch
• Confirm the operation completed successfully

Important: Before merging, verify:

• All CI checks have passed (if still in progress, use /watch-ci and stop), unless --no-wait was passed
• The PR has been approved
• You are on the correct branch

If any CI checks fail, report the failure and do not merge (unless --no-wait was explicitly passed — see below).

--no-wait (-now) option

If --no-wait or -now is passed, skip the CI watch entirely and merge the PR immediately, regardless of check status:

1. Do NOT invoke /watch-ci
2. Do NOT block on or wait for CI checks to complete
3. Run gh pr merge --merge --delete-branch straight away

• If GitHub rejects the merge because branch protection requires passing checks, report the error to the user and stop. Do not retry, do not bypass with admin merge unless the user explicitly asks

4. Then proceed to the post-merge steps (--close / --keep-issue / --watch-ci) as normal

When to use: the user has already verified locally that the changes are good (or doesn't care about CI for this merge) and wants the PR merged now without waiting on the pipeline. This is an explicit opt-in — never assume --no-wait from context.

Note: --no-wait only skips waiting for CI checks. The --watch-ci (-w) option, which watches post-merge CI on the target branch, is independent and still works alongside -now.

--close (-c) option

If --close or -c is passed, after the PR is successfully merged:

1. Find the parent issue linked to this PR

• Check PR body for "Closes #N", "Fixes #N", "Resolves #N" patterns
• Also check gh pr view --json closingIssuesReferences

2. If a linked issue is found and the PR was merged successfully:

• Check if it is an epic issue (one that holds sub-issues):

  a. Fetch the issue body: gh issue view <number> --json body b. Look for task list entries referencing issues in the body:

  • Patterns: - [ ] #N, - [x] #N, - [ ] owner/repo#N, - [x] owner/repo#N

    c. Also try the GitHub sub-issues API: gh api repos/{owner}/{repo}/issues/<number>/sub_issues (this returns a list if the newer GitHub sub-issues feature is in use)

• If sub-issues are found (either from the body task list or the API):

  • For each sub-issue:
    • Confirm it is still open: gh issue view <sub-issue-number> --json state
    • If open, close it: gh issue close <sub-issue-number>
    • Report each closure
  • After all sub-issues are closed, close the epic issue itself:
    • gh issue close <number>
    • Report that the epic issue was closed

• If no sub-issues are found (regular issue):

  • gh issue close <number>
  • Report which issue was closed

--keep-issue (-k) option

If --keep-issue or -k is passed, after the PR is successfully merged:

1. Find the parent issue linked to this PR (same lookup as --close)
2. Instead of closing the issue, prepend [PR-Merged][Confirm] to the issue title:

• gh issue edit <number> --title "[PR-Merged][Confirm] <original title>"
• This signals that the PR was merged but the issue needs user confirmation before closing

3. Report which issue was updated

Note: --keep-issue and --close are mutually exclusive. If both are passed, --keep-issue takes precedence.

--watch-ci (-w) option

If --watch-ci or -w is passed, after the PR is successfully merged:

1. Determine the merge target branch (the base branch of the PR)
2. Check if there are any CI workflow runs triggered on the merge target branch for the merge commit:

• gh run list --branch <base-branch> --limit 5 --json databaseId,name,status,conclusion

3. If CI runs exist on the target branch, invoke /watch-ci to monitor the merge target branch CI in the background

• /watch-ci already handles merged PRs — it will detect the merged state and watch the target branch CI

4. If no CI runs exist on the target branch, skip and report: "No CI detected on the merge target branch."

This option is only activated when explicitly passed. Without -w, pr-complete does not watch post-merge CI.