| name | review-staged-changes |
| description | Reviews staged git changes for code quality, maintainability, readability, and potential regressions. Verifies changes make sense in context, improve maintainability, enhance readability, and don't introduce side effects. Use when reviewing staged changes, examining git diffs, or when the user asks to review modifications before committing. |
| source | lichens |
Review Staged Changes
Reviews staged git changes to ensure they improve code quality, maintainability, and readability without introducing regressions.
Workflow
When reviewing staged changes:
- Get the staged diff:
git diff --cached or git diff --staged
- Analyze each change against the four criteria below
- Provide structured feedback using the template in this skill: templates/review-summary.md (relative to the skill directory)
Review Criteria
1. Contextual Sense
Verify changes align with the stated purpose:
- Do the modifications address the intended goal?
- Are related changes grouped logically?
- Is the scope appropriate (not too broad, not too narrow)?
- Are any unrelated changes included that should be in a separate commit?
2. Regression Prevention
Identify potential breaking changes:
- Behavior changes: Does the code behave differently than before?
- API changes: Are function signatures, props, or interfaces modified?
- Side effects: Could changes affect other parts of the codebase?
- Dependencies: Are imports, dependencies, or external integrations affected?
- Edge cases: Are existing edge cases still handled correctly?
Red flags:
- Removing error handling without replacement
- Changing return types or function signatures
- Modifying shared utilities without checking usages
- Removing validation or checks
- Changing default values that other code might depend on
3. Maintainability & Evolvability
Assess long-term code health:
- Structure: Is code better organized (extracted functions, clearer modules)?
- Complexity: Is cyclomatic complexity reduced?
- Coupling: Are dependencies reduced or better managed?
- Testability: Is code easier to test (pure functions, dependency injection)?
- Documentation: Are complex parts documented?
- Patterns: Are established patterns followed consistently?
Signs of improvement:
- Extracting reusable utilities
- Reducing nested conditionals
- Breaking large functions into smaller ones
- Using consistent naming conventions
- Following project architecture patterns
4. Readability
Evaluate code clarity:
- Naming: Are variables, functions, and types clearly named?
- Structure: Is code flow easy to follow?
- Comments: Are comments helpful (explain "why", not "what")?
- Formatting: Is code consistently formatted?
- Magic numbers: Are constants extracted and named?
Signs of improvement:
- More descriptive variable names
- Reduced nesting levels
- Clearer control flow
- Better type annotations
- Consistent code style
Common Patterns to Check
Refactoring Patterns
Good refactoring:
- Extract function → Verify all call sites updated
- Rename variable → Verify all references updated
- Move code → Verify imports and dependencies updated
Risky refactoring:
- Changing shared utilities without checking all usages
- Modifying type definitions without updating consumers
- Removing "unused" code that might be used dynamically
Code Quality Improvements
Verify improvements are real:
- Not just moving code around
- Actually reducing complexity
- Actually improving readability
- Making code more testable, not just prettier
Readability Improvements
Ensure clarity gains:
- Names are actually more descriptive
- Structure is genuinely easier to follow
- Comments add value, not noise
When to Flag Issues
Flag changes if:
- Critical: Changes break existing functionality or introduce bugs
- Warning: Changes might cause issues or reduce maintainability
- Suggestion: Changes could be improved but aren't problematic
Provide specific examples from the diff when flagging issues.
