review

name

review

description

Architectural and code quality review of Android code. Two-pass check: (1) architectural rule compliance — 8 categories, (2) code quality — naming, duplication, error handling, security, performance, maintainability. Use after implementation to verify quality. <example> Context: User created a new feature and wants to check its quality user: "review the authorization feature" assistant: "Using review skill for a two-pass check of the auth feature." </example> <example> Context: User refactored code and wants to verify correctness user: "check the profile refactoring" assistant: "Using review skill to check architecture and code quality of the profile feature." </example> <example> Context: User wants to check code before committing user: "check my code before commit" assistant: "Using review skill for a full check of the modified files." </example>

Review — Architecture & Code Quality Review

You perform a comprehensive review of Android code: architecture + quality. Two passes, one verdict.

Input

Task from user: $ARGUMENTS

Step 1: Determine the scope

1. Get the feature name or file list from the user
2. If a feature is specified — find all files via Glob:
   • **/feature/{featureName}/**/*.kt
   • **/features/{featureName}/**/*.kt
   • **/{featureName}/**/*.kt
3. If specific files are specified — use them

Step 2: Read the rules

1. Required: read $CLAUDE_PLUGIN_ROOT/rules/android-core.md — the primary source of architectural rules
2. Memorize all rules — they serve as the reference for the check

Step 3: Read all files in scope

Read each feature file using the Read tool. Do not skip any file.

Step 4: Pass 1 — Architecture Compliance

Check each file against all 8 categories. For each violation, record the file, line, and rule.

Category 1: Package Structure

• Folders match the standard (presentation/screen, presentation/view, presentation/viewmodel, domain/usecase, domain/repository, data/datasource, data/repository, di)
• Each class is in the correct folder
• Each class is in a separate file

Category 2: Screen

• Uses collectAsStateWithLifecycle() for state
• Uses CollectWithLifecycle {} for actions
• No remember, logic, or computations in Screen
• No UI state in Screen (PagerState, ScrollState, LazyListState belong in View)

Category 3: View

• Signature: viewState + eventHandler parameters
• No business logic remember or side-effects
• UI state (rememberPagerState, rememberScrollState, rememberLazyListState) is ALLOWED in View — this is where it belongs
• LaunchedEffect / snapshotFlow for syncing UI state (e.g. pager page changes) with eventHandler is ALLOWED in View
• Preview: private fun {Feature}View_Preview in {App}Theme
• No direct use of MaterialTheme
• No hardcoded colors or typography

Category 4: ViewModel

• Extends BaseSharedViewModel
• override fun handleEvent for event handling
• updateState { it.copy(...) } for state updates
• No Compose imports (androidx.compose.*)
• No direct Repository calls — only through UseCase

Category 5: ViewState / Event / Action

• Each in a separate file
• ViewState — data class with default values for all fields
• ViewEvent — sealed class
• ViewAction — sealed class

Category 6: UseCase

• Extends UseCase
• suspend fun execute(...) — NOT operator fun invoke
• Returns Result<T>
• Depends only on Repository (not on other UseCases, DataSources, etc.)

Category 7: Repository

• Has an I{Feature}Repository interface
• Implementation is in data/repository/
• Depends only on DataSources (not on other Repositories, UseCases, etc.)

Category 8: DI Module

• All feature dependencies are registered (ViewModel, UseCases, Repository, DataSources)
• Style matches the project framework (Koin module {} / Kodein bind<>())

Step 5: Pass 2 — Code Quality

Check the code across 6 quality categories:

1. Naming & Readability

• Class, function, and variable names are clear and follow Kotlin conventions
• Functions are not too long (>30 lines is a reason to reconsider)
• Code reads top-to-bottom without needing to jump around the file

2. Duplication (DRY)

• No copy-paste between files
• Shared logic is extracted into reusable components
• No repeating strings/blocks in View (extract into a separate Composable)

3. Error Handling

• UseCase returns Result, errors are handled
• ViewModel handles Result.failure and shows an error to the user
• No swallowed exceptions (empty catch)
• No force-unwrap (!!) without justification

4. Security

• No hardcoded API keys, passwords, or secrets
• No logging of sensitive data
• Proper token storage (not in SharedPreferences without encryption)

5. Performance

• No heavy operations in Composable functions
• No unnecessary recompositions (stable parameters, correct keys)
• No blocking calls on the Main thread
• Correct coroutine usage (proper dispatcher)

6. Maintainability

• Code is easy to extend with new functionality
• Dependencies are injected, not created internally
• No God-objects (a class doing too much)
• Magic numbers/strings are extracted into constants

Step 6: Report generation

Combine the results of both passes into a single report:

## Scope
Files reviewed: {list of all reviewed files}
Rules: rules/android-core.md [+ references if used]

## Verdict
**PASS** / **FAIL**

PASS — if there are no Critical or Important issues.
FAIL — if there is at least one Critical or Important issue.

## Issues
{N}. [{Category}] {File.kt}:{line}
   Severity: Critical / Important / Suggestion
   Rule: {rule name or description}
   Problem: {concrete description of what's wrong}

## Strengths
{2-3 things done well — always find something positive}

## Summary
Files: {N}, Issues: {N} (Critical: {N}, Important: {N}, Suggestions: {N})

Severity guidelines:

• Critical — architectural violation, potential crash, data leak
• Important — deviation from the standard, potential problem
• Suggestion — quality improvement, not mandatory to fix

Rules

• Read-only — NEVER modify code. Only read and analyze.
• Specificity — specify exact files and line numbers for each issue.
• Objectivity — check against project rules, not personal preferences.
• Completeness — check ALL files in scope, do not skip any.
• Balance — always note the strengths of the code, not just the problems.