| name | implement |
| description | Android feature implementation: creating from scratch, extending existing features, or refactoring to match the architectural standard. Automatically determines the working mode based on context. Use for any tasks involving writing/modifying Android code.
<example>
Context: User wants to create a new screen
user: "create an authorization screen with email and password"
assistant: "Using implement skill in create mode to build the auth feature."
</example>
<example>
Context: User wants to add functionality to an existing screen
user: "add pagination to the catalog screen"
assistant: "Using implement skill in modify mode to extend the catalog feature."
</example>
<example>
Context: User wants to bring code up to standard
user: "refactor the profile screen to match our architecture"
assistant: "Using implement skill in refactor mode to migrate the profile feature."
</example>
<example>
Context: A list of architectural violations was received from review
user: "fix the violations from the review"
assistant: "Using implement skill to fix architectural violations."
</example>
|
Implement — Android Feature Implementation
You implement Android feature layers strictly following the project's architectural rules.
Input
Task from user: $ARGUMENTS
Step 1: Determine the working mode
Automatically determine the task type:
CREATE mode — feature does not exist
Triggers:
- User asks to create a new screen/feature
- Feature not found by Glob patterns in the project
- Full structure needs to be built from scratch
MODIFY mode — feature exists, needs to be extended
Triggers:
- User asks to add/change functionality
- Feature found in the project
- Needs to be extended, not built from scratch
REFACTOR mode — feature exists, needs to be brought to standard
Triggers:
- User asks to refactor/migrate
- A list of violations received from review skill
- Needs to be brought to the architectural standard
- DI migration (Kodein → Koin)
- Screen/View separation
FIX mode — fixing specific violations
Triggers:
- A list of Issues received from review or test-ui skill
- Specific problems need to be fixed
- Category → files mapping:
[Structure] → packages and files[Screen] → {Feature}Screen.kt[View] → {Feature}View.kt[ViewModel] → {Feature}ViewModel.kt[ViewState/Event/Action] → corresponding files[UseCase] → *UseCase.kt[Repository] → *Repository.kt[DI] → *DiModule.kt / *Module.kt[Rendering] → {Feature}View.kt[Interaction] → {Feature}View.kt + ViewModel[Navigation] → {Feature}Screen.kt + ViewModel[Data] → ViewModel + ViewState[Accessibility] → {Feature}View.kt[Crash] → ViewModel / UseCases
Step 2: Project preparation
- Determine the base package — from CLAUDE.md or existing files
- Determine the DI framework —
koin or kodein from build.gradle or existing modules
- Determine navigation — from existing Screen files
- Find BaseSharedViewModel — full import path
- Find UseCase interface — full import path
- Read the rules —
$CLAUDE_PLUGIN_ROOT/rules/android-core.md (required)
Step 3: Execute by mode
CREATE mode
Read references: $CLAUDE_PLUGIN_ROOT/skills/implement/references/architecture.md, $CLAUDE_PLUGIN_ROOT/skills/implement/references/base-viewmodel.md, $CLAUDE_PLUGIN_ROOT/skills/implement/references/theme-system.md
Use examples/ as a template for each file.
Creation order:
- Create the folder structure:
feature/{featureName}/
presentation/screen/
presentation/view/
presentation/viewmodel/
domain/usecase/
domain/repository/
data/datasource/
data/repository/
di/
- Generate files in this order:
{Feature}ViewState.kt — data class with default values{Feature}ViewEvent.kt — sealed class of UI events{Feature}ViewAction.kt — sealed class of one-time actions{Feature}ViewModel.kt — extends BaseSharedViewModel{Feature}Screen.kt — thin adapter{Feature}View.kt — pure UI with Preview- Use cases — one per action
I{Feature}Repository.kt — interface{Feature}Repository.kt — implementation- DataSources — Local and/or Remote
{Feature}DiModule.kt — DI module
MODIFY mode
Read references: $CLAUDE_PLUGIN_ROOT/skills/implement/references/modification-rules.md
- Read all feature files (Screen, View, ViewModel, ViewState, ViewEvent, ViewAction, UseCases, Repository, DataSources, DI)
- Plan changes — what to add/modify
- Safe modification rules:
- Do not break existing contracts (do not remove fields, do not change signatures)
- New logic — only in ViewModel
- New UI — only in View
- New data — through UseCase → Repository → DataSource
- Each new class — in a separate file
- Update the DI module
REFACTOR mode
Read references: $CLAUDE_PLUGIN_ROOT/skills/implement/references/migration-guide.md, $CLAUDE_PLUGIN_ROOT/skills/implement/references/architecture.md
- Audit — check against the checklist from architecture.md
- Migration plan:
- Create missing package structure
- Split files (separate classes)
- Create missing layers
- Refactor ViewModel to BaseSharedViewModel
- Separate Screen and View
- Migrate DI (if needed)
- Execution — atomic steps, code compiles after each one
- Validation — re-audit
FIX mode
- Get the list of Issues (from review or test-ui)
- For each issue: find the file → find the problematic spot → fix strictly according to the rule
- Do not touch code that already conforms to the standard
- UI state rule: If review flags
remember/LaunchedEffect in Screen — move them to View, do NOT delete them. PagerState, ScrollState, LazyListState and related snapshotFlow belong in View, never in Screen.
- After all fixes — validation
Step 4: Validation (for all modes)
Step 5: Output
- Summary — what was done and in which mode
- Files — list of created/modified/deleted files
- Full code — code of all files
- Architecture validation — confirmation of rule compliance
