reviewing-local-changes

name: reviewing-local-changes
description: Review the current branch's changes for code quality, test coverage, security, best practices, and product/API alignment. Use when asked to perform a code review.
model: inherit
readonly: true
disallowedTools: Write, Edit
skills:
  - assessing-external-test-risk
  - reviewing-readability
  - reviewing-pr-description
memory: user

Reviewing Local Changes

You are performing a code review on the current branch's changes.

Context

• **Repository**: streamlit/streamlit
• **Main branch**: develop
• **Head branch**: !`git branch --show-current`

Gather additional context as needed:

`git` and the GitHub CLI (`gh`) are available for read operations. First, determine the base branch for comparison. Note that a PR may not exist yet for the current branch, in which case `develop` should be used as base branch:

# Determine base branch: use PR's target branch if available, otherwise fall back to develop
# This supports stacked PRs where the base might be another feature branch
# If no PR exists yet, this falls back to 'develop'
BASE_BRANCH=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || echo "develop")
echo "Base branch: $BASE_BRANCH"

# Fetch the base branch to ensure accurate comparison
git fetch origin "$BASE_BRANCH"

# List all changed files (committed, staged, and unstaged) compared to base
git diff --name-only "origin/$BASE_BRANCH...HEAD"  # committed changes on the branch
git diff --name-only HEAD                          # uncommitted changes (staged + unstaged)

# Full diff of all changes compared to base (committed + uncommitted)
git diff "origin/$BASE_BRANCH"

You can also get PR details if a PR exists:

# Check if a PR exists for the current branch
gh pr view --json number,title,url,body,headRefName,baseRefName -R streamlit/streamlit || echo "No PR found for this branch."

Goal

Review this branch's changes and ensure the changes are bug-free, backwards compatible, aligned with Streamlit's product and API principles, and ready for merge.

Review Checklist

• Unit and e2e tests are covering the changes well.
• Important: Changes follow the best practices documented in the relevant `AGENTS.md` files (read the ones that apply to the changed files):
• `e2e_playwright/AGENTS.md` — for e2e tests (inside `e2e_playwright/`)
• `frontend/AGENTS.md` — for frontend changes and unit tests (inside `frontend/`)
• `lib/tests/AGENTS.md` — for Python unit tests (inside `lib/tests/`)
• `lib/AGENTS.md` — for any Python changes (`*.py` files)
• `lib/streamlit/AGENTS.md` — for any Python library changes (inside `lib/streamlit/`)
• `lib/streamlit/.agents/skills/AGENTS.md` — for bundled agent skills (inside `lib/streamlit/.agents/skills/`)
• `proto/streamlit/proto/AGENTS.md` — for protobuf changes (inside `proto/streamlit/proto/`)
• Product alignment is explicitly assessed for user-facing changes. Treat a change as user-facing

when it adds or modifies a public API, configuration option, CLI surface, rendered UI or interaction, default, error message, or other externally observable behavior.

• Read `specs/AGENTS.md` and evaluate the change against its "Principles of Streamlit API

Design."

• Search `specs/` for a relevant product spec. Product decisions explicitly described in a

product spec that is already merged into the PR's base branch are considered approved and aligned; do not relitigate them. Instead, verify that the implementation follows the spec and separately assess any user-facing behavior that the merged spec does not cover. A new spec that exists only on the current PR is not already approved by this rule.

• Small, incremental edits to an already-merged product spec may land on the same

implementation PR. They do not require a separate spec PR. Treat those edits as expected spec maintenance; do not request changes solely because the spec was updated here. Still assess any newly introduced product decisions for alignment.

• Read the PR body for explicit product-approval context. If it states that specific

product-related decisions were explicitly approved, treat only those decisions as approved and aligned; do not relitigate them. Verify that the implementation matches the approved decisions and separately assess any user-facing behavior outside their stated scope. Do not infer approval from vague wording or the mere presence of product discussion.

• A brand-new user-facing feature or significant public API change requires a product spec

already merged into the base branch unless the PR body explicitly documents approval of both the product change and proceeding without a merged spec. If neither condition is met, call this out as a merge-blocking Product Alignment issue: merge the product spec first, then the implementation (see `specs/README.md` and `specs/AGENTS.md`). A spec that exists only on this implementation PR (not as an incremental update to a spec already on the base branch) is not sufficient. Bug fixes, DevOps work, and small non-controversial enhancements do not need a spec.

• If neither a merged spec nor explicit PR-body approval covers a product decision, that

absence is not approval. Request changes for material product/API alignment issues.

• Inspect analogous Streamlit APIs, configs, and behaviors. Check that the proposed surface

uses established names, defaults, interaction patterns, return types, and error behavior. For public APIs, follow the "Docstrings for Public API" best practices in `lib/streamlit/AGENTS.md` and compare docstrings with analogous API methods and functions for consistent terminology, parameter descriptions, documented behavior, and examples.

• Confirm that the change solves a clear user problem, keeps the common case simple, exposes

complexity progressively, composes with existing features, and adds no more permanent user-f