---
name: branch-review-analyze
description: "Analyze the current branch for bugs, optimization opportunities, maintainability issues, and text problems after reading the diff and pyproject.toml. Use when: analyze branch review findings, think through improvements, classify code review issues, анализ ревью ветки, найти улучшения, подумать как улучшить код."
argument-hint: "Review packet or target area to analyze"
---

# Branch Review: Analyze Improvements

This skill turns raw branch context into defensible review findings.

## Analysis Rules

- Use `pyproject.toml` constraints as the default source of truth for Python version, linting, typing, formatting, and test behavior
- Prefer correctness over style-only comments
- Do not suggest changes that conflict with configured versions, strictness, or ignored rules
- Review both changed lines and immediate behavioral context
- Include spelling and wording issues when they affect docs, comments, user-facing text, tests, or developer clarity

## What to Look For

### Critical

- bugs, broken logic, wrong conditions, missing edge cases
- unsafe refactors and regressions introduced by the branch
- typing or API misuse that violates configured tooling or likely runtime behavior
- tests that no longer validate the actual behavior

### Important

- performance issues in hot paths
- duplicated logic introduced by the branch
- brittle or incomplete tests
- error handling gaps
- config mismatches against `pyproject.toml`
- maintainability problems that make the changed code harder to evolve

### Optional

- cleanup opportunities with low risk
- clearer naming
- smaller structure improvements
- modern idioms allowed by the configured Python version

### Text and Spelling

- typos in comments, docs, tests, log messages, exceptions, CLI output, and UI strings
- misleading wording or terminology inconsistencies

## Procedure

### Step 1 — Reconcile Diff with Config

For each changed Python-related file, compare the implementation against:
- effective Python version
- configured linter rules and ignores
- type-checking modes
- test config and markers

### Step 2 — Find Root Causes

Avoid surface comments. For each issue, identify:
- what changed
- why it is risky or suboptimal
- what the smallest correct improvement is

### Step 3 — Classify Findings

Produce findings in four groups:
- `Critical`
- `Important`
- `Optional`
- `Text and Spelling`

Each finding should contain:
- title
- affected file or scope
- reasoning
- concrete recommended change
- whether it is safe to auto-apply

### Step 4 — Note Validation Strategy

For every auto-applicable change, specify how it should be validated:
- targeted tests
- linter or type-check command
- smoke import or command run
- no validation available

## Output Template

```md
## Review Findings

### Critical
1. <title>
   - scope: ...
   - why: ...
   - change: ...
   - auto-apply: yes/no
   - validate: ...

### Important
...

### Optional
...

### Text and Spelling
...
```

Do not edit files in this skill.