Finalizing PR

SkillDev tools

Finalizing-pr is a skill that prepares a branch for merging. It guides an agent through building the project, cleaning up code and docs, running checks, and reviewing its own changes. When the branch is ready, it pushes it and creates a pull request using repo templates and required labels, or updates an existing one.

Use Finalizing PR in Claude, ChatGPT or Ahel Desktop

Free. Sign in, add Finalizing PR and connect your AI. About a minute.

Also: Claude Code · Cursor · Codex

Then ask your AI: use the Finalizing PR skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have a repository with a branch containing changes you want to merge into a target branch.

Finalizing PRStart free

What your AI can do with it

  • Builds the project and fixes documentation before merging
  • Simplifies code on the branch
  • Runs format and validation checks twice
  • Reviews its own changes and addresses the findings
  • Creates a pull request using repo templates and required labels
  • Updates an existing PR and optionally loops through automated reviews until approval

Getting started

  1. Have a repository with a branch containing changes you want to merge into a target branch.
  2. Add the finalizing-pr skill to your agent's available skills.
  3. Tell the agent you are ready to merge the changes into the target branch.
  4. Let the agent run its checks, push the branch, and create or update the pull request.

What this skill tells your AI

The instructions your AI receives, as published by streamlit/streamlit in .claude/skills/finalizing-pr/SKILL.md and read by ahel’s review.

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

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 (they require manual updates).

9. Create or update PR

Note: If currently on develop, create a new branch first following the naming conventions in wiki/pull-requests.md.

Check if a PR exists for the current branch:

gh pr view --json number,title,url

If no PR exists, create one following the guidelines in wiki/pull-requests.md (please read!) and the title/description guidance in the /reviewing-pr-description skill. Add appropriate labels and fill in the body based on .github/pull_request_template.md.

Link related issues: Add - Closes #12345 to the PR description for any known GitHub issues this PR resolves.

Required labels:

CategoryOptions
Impactimpact:users (affects user behavior) OR impact:internal (no user behavior change)
Change typechange:feature, change:bugfix, change:chore, change:refactor, change:docs, change:spec, change:other

Note: PRs labeled change:spec (for spec/design documents only) are exempt from Impact label requirements.

# Push branch to origin first (required for gh pr create in non-interactive mode)
git push -u origin HEAD

# Create the PR
gh pr create --base develop --title "[type] Description" --body "$(cat <<'EOF'
## Describe your changes

- Change 1
- Change 2

## GitHub Issue Link (if applicable)

- Closes #12345

## Testing Plan

- [x] Unit Tests (JS and/or Python)
EOF
)" --label "impact:users,change:feature"

If PR exists, check if description needs updating based on current changes.

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

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 once so it can wait for CI and address comments. Do this exactly once, whether step 11 was approved or ran out of iterations. Do not re-apply ai-final-review. After /fixing-pr, commit and push remaining changes.

13. Post agent metrics

Post the agent metrics to the PR body:

uv run python scripts/log_agent_metrics.py --post

Signals

GitHub stars
46k
Forks
4k
Last commit
Oct 2026

Questions

When should I use this skill?
Use it when you are ready to merge changes into the target branch and want the branch finalized, checked, and turned into a pull request.
Does it create a new PR or update an existing one?
It creates a pull request using repo templates and required labels if none exists, or updates an existing one.
Can it handle review feedback?
Yes. It addresses its own review findings and can optionally loop through automated reviews until approval.
Advanced
Item type
skill
Key
finalizing-pr
Source
github.com/streamlit/streamlit