Reviewing Code

• The version pin in pyproject.toml must match. If the change breaks compatibility with the previously-pinned minimum version, the minimum version must be bumped. Otherwise users on the old version get a regression.
• If backwards compatibility with the old version is desired, the code must handle both versions (e.g., try/except, version check). Simply deleting the old API usage without bumping the pin is always wrong — it silently breaks users on the old version.
• Lock file (uv.lock) changes should be scoped to the PR's purpose. A PR fixing a ty compatibility issue should not also include unrelated dependency version bumps (anthropic, google-auth, etc.) from running uv sync --upgrade. These create noise and make the diff harder to review.

API design and naming

Identify confusing patterns or non-idiomatic code:

• Parameter values that contradict defaults
• Mutable default arguments
• Unclear naming that will confuse future readers
• Inconsistent patterns with the rest of the codebase

Specific improvements

Provide actionable feedback, not generic observations.

User ergonomics

Think about the API from a user's perspective. Is it intuitive? What's the learning curve?

For Agent Reviewers

1. Read the full context: Examine related files, tests, and documentation before reviewing
2. Check against established patterns: Look for consistency with codebase conventions
3. Verify functionality claims: Understand what the code actually does, not just what it claims
4. Consider edge cases: Think through error conditions and boundary scenarios

What to Avoid

• Generic feedback without specifics
• Hypothetical problems unlikely to occur
• Nitpicking organizational choices without strong reason
• Summarizing what the PR already describes
• Star ratings or excessive emojis
• Bikeshedding style preferences when functionality is correct
• Requesting changes without suggesting solutions
• Focusing on personal coding style over project conventions

Tone

• Acknowledge good decisions: "This API design is clean"
• Be direct but respectful
• Explain impact: "This will confuse users because..."
• Remember: Someone else maintains this code forever

Decision Framework

Before approving, ask:

1. Does this PR achieve its stated purpose?
2. Is that purpose aligned with where the codebase should go?
3. Would I be comfortable maintaining this code?
4. Have I actually understood what it does, not just what it claims?
5. Does this change introduce technical debt?

If something needs work, your review should help it get there through specific, actionable feedback. If it's solving the wrong problem, say so clearly.

Comment Examples

Good comments:

Checklist

Before approving, verify:

• All required development workflow steps completed (uv sync, prek, pytest)
• Changes align with repository patterns and conventions
• API changes are documented and backwards-compatible where possible
• Error handling follows project patterns (specific exception types)
• Tests cover new functionality and edge cases
• The change advances the codebase in the intended direction