code-review

Project context: Values in angle brackets below (e.g. <scheme>, <JIRA_KEY>, <flag-key-enum>) are resolved at runtime — detect them from the project (xcodebuild -list -json for the scheme, git/gh for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.

Code Quality Review

You are performing a code quality review on new or modified files in the current branch.

Task

Review all new and modified Swift files (excluding test files) in the current branch, applying the principles below. Then apply the fixes.

Scope

1. Identify changed files: Run git diff --name-only HEAD~1 or git status to find new/modified Swift source files
2. Read each file fully before suggesting changes
3. Apply fixes incrementally, confirming each category of change

Principles to Apply

DRY (Don't Repeat Yourself)

• Look for duplicated code blocks, repeated patterns, or copy-pasted logic
• Extract shared behavior into helper methods or computed properties
• If 3+ lines are repeated across switch cases or conditionals, extract them

SOLID

• Single Responsibility: Each method/class should have one reason to change — one job, one concern
• Open/Closed: Classes should be open for extension but closed for modification — prefer adding computed properties to enums over external switch statements, use protocol extensions to add behavior
• Liskov Substitution: Subclasses/implementations must be substitutable for their base types without breaking behavior — don't restrict capabilities or violate contracts of the parent type
• Interface Segregation: Don't force classes to depend on interfaces they don't use — split large protocols into smaller, focused ones aligned with client needs
• Dependency Inversion: High-level modules should depend on abstractions, not concrete types — use protocols for dependencies, inject them rather than hardcoding