/finalizing-pr

name: finalizing-pr
description: Finalizes branch changes for merging by simplifying code, running checks, reviewing changes, and creating a PR if needed. Use when ready to merge changes into the target branch.

Finalizing PR

Prepares the current branch for merge by running quality checks, simplifying code, and creating a PR if one doesn't exist.

**Be fully autonomous** — Do NOT stop or pause to ask for confirmation. Go from current state to merge-ready PR without human intervention. Note any open questions or ambiguities in a PR conversation comment (under the Conversation tab) rather than blocking on them.

Workflow

Follow these steps in order. **Run all subagents in foreground** (not background) unless otherwise specified—wait for each to complete before proceeding. **Subagent model**: use the same model as this session on every launch (`model: inherit` / omit any model override). Do not switch to a different or faster model unless the user explicitly requests it.

> **Note:** For small changes (documentation tweaks, test-only tweaks, one-liners, or other mini-changes), you can skip steps 1, 2, 3, 6, 7, and 8.

1. Build and install

Run `make all` in a subagent to ensure the build and installation are up-to-date. Wait for completion before proceeding.

make all

2. Update internal docs

Run the `/updating-internal-docs` skill in a background subagent to auto-fix internal documentation issues. Instruct it to apply all recommended fixes to internal docs issues related to the local changes.

3. Simplify changes

Run the `simplifying-local-changes` subagent to clean up and simplify the code changes. Wait for completion before proceeding.

4. Run autofix

Run autofix in a subagent to fix formatting and linting issues. Wait for completion before proceeding.

make autofix

5. Run checks (first pass)

Run the /checking-changes skill in a subagent (uses `make check`) to validate the changes. Wait for completion, then fix any issues found before proceeding. Don't run other checks besides `make check` in this step.

6. Review changes

Run the `reviewing-local-changes` subagent to review the changes. Wait for completion and read the review output.

7. Address review feedback

Review the recommendations from step 6. For each recommendation:

• If valid and improves code quality: implement the change
• If not applicable or would over-engineer: skip with brief reasoning. This includes fixes for rare, low-impact edge cases that would add new state, abstractions, or long special-case branches (see the proportionality check in `/addressing-pr-review-comments`)

8. Run checks (second pass)

Run the /checking-changes skill in a subagent with `E2E_CHECK=true make check` to also run changed e2e tests. Wait for completion, then fix any issues found before proceeding. Snapshot mismatches can be ignored while iterating. On a pull request, add the `update-snapshots` label and merge the snapshot PR the workflow opens.

9. Create or update PR

Run the `/creating-pull-requests` skill to create or update the PR. Steps 11 and 12 rely on the `impact:*` and `change:*` labels it sets.

10. Upload intermediate files

If relevant intermediate files exist (specs, plans, implementation notes in `work-tmp/` or untracked in `specs/`), run the `/sharing-pr-agent-artifacts` skill to push them to the wiki and comment on the PR with links.

11. AI review and fix loop

Run the AI review and fix loop up to 5 times. After each review, always run `fixing-pr` so it can wait for CI and address comments, then exit if that review was approved:

for iteration 1 to 5:
    1. Trigger AI review by applying the "ai-review" label
    2. Run the `fixing-pr` subagent in foreground to wait for CI, fix failures, and address review comments
    3. Check the latest AI review verdict
    4. If it is "approved" → exit loop

**Triggering AI review:**

gh pr edit --add-label "ai-review"

**Checking AI review verdict:**

The AI review posts results as a PR review from the `github-actions` bot. These contain a hidden marker:

<!-- streamlit-ai-review run_id="..." timestamp="..." -->

To find the latest AI review and extract the verdict:

PR_NUM=$(gh pr view --json number -q '.number')

# Get the verdict from the latest AI review
gh api --paginate "repos/streamlit/streamlit/pulls/${PR_NUM}/reviews" \
  | jq -s '[.[][] | select(.user.login == "github-actions[bot]" and (.body | contains("<!-- streamlit-ai-review")))] | sort_by(.submitted_at) | last | .body' \
  | grep -A2 "## Verdict"

The verdict section contains a bold keyword indicating the result:

• **`**APPROVED**`** → exit loop, PR is ready
• **`**CHANGES_REQUESTED**`** → continue iterating, address the feedback

Do not start another iteration after an `APPROVED` verdict, even if `fixing-pr` pushed follow-up CI fixes. Those commits are covered by CI but not by the AI review.

12. Final AI review

After the review loop, apply `ai-final-review` once. When the PR has both `change:feature` and `impact:users`, also apply `ai-qa-test` so AI QA runs on that user-facing feature.

Wait until a `queued` or `in_progress` `ai-pr-review.yml` run shows up for this branch, then start `/fixing-pr` — it returns immediately if nothing is queued yet:

gh pr edit --add-label "ai-final-review"
# Only when the PR has both change:feature and impact:users:
gh pr edit --add-label "ai-qa-test"

gh run list --branch "$(git branch --show-current)" --workflow ai-pr-review.yml --status queued
gh run list --branch "$(git branch --show-current)" --workflow ai-pr-review.yml --status in_progress

Run `/fixing-pr` exactly once, whether step 11 was approved or ran out of iterations, so it can wait for CI and address comments. Tell `/fixing-pr` to skip `ai-qa-testing.yml` when polling CI; that workflow posts its report as a PR comment for a maintainer to review and adds `do-not-merge` on `FAIL`