planning-android-implementation

Implementation Planning

This skill takes a refined specification (ideally from the refining-android-requirements skill) and produces a phased implementation plan with architecture design, file inventory, and risk assessment.

Prerequisite: A clear set of requirements. If requirements are vague or incomplete, invoke the refining-android-requirements skill first.

Step 1: Classify Change

Determine the change type to guide scope and planning depth:

State the classification and rationale before proceeding.

Step 2: Codebase Exploration

Search the codebase to find reference implementations and integration points. Use the discovery commands from the build-test-verify skill as needed.

Find Pattern Anchors

Identify 2-3 existing files that serve as templates for the planned work:

**Pattern Anchors:**
1. [file path] — [why this is a good reference]
2. [file path] — [why this is a good reference]
3. [file path] — [why this is a good reference]

Map Integration Points

Identify files that must be modified to integrate the new work:

• Navigation: Nav graph registrations, route definitions
• Dependency Injection: Hilt modules, @Provides / @Binds functions
• Data Layer: Repository interfaces, data source interfaces, Room DAOs
• API Layer: Retrofit service interfaces, request/response models
• Feature Flags: Feature flag definitions and checks
• Managers: Single-responsibility data layer classes (see docs/ARCHITECTURE.md Managers section)
• Test Fixtures: Shared test utilities in src/testFixtures/ directories
• Product Flavor Source Sets: Code in src/standard/ vs src/main/ for Play Services dependencies

Document Existing Patterns

Note the specific patterns used by the pattern anchors:

• State class structure (sealed class, data class fields)
• Action/Event naming conventions
• Repository method signatures and return types
• Test structure and assertion patterns

Step 3: Architecture Design

Produce an ASCII diagram showing component relationships for the planned work:

┌─────────────────┐
│   Screen        │ ← Compose UI
│  (Composable)   │
└────────┬────────┘
         │ State / Action / Event
┌────────▼────────┐

Adapt the diagram to show the actual components planned. Consult docs/ARCHITECTURE.md for full data layer patterns and conventions.

Design Decisions

Document key architectural decisions in a table:

Step 4: File Inventory

Files to Create

Include in file inventory:

• ...Navigation.kt files for new screens
• ...Module.kt Hilt module files for new DI bindings
• Paired test files (...Test.kt) for each new class

Files to Modify

Risk levels:

• Low: Additive changes (new entries in nav graph, new bindings in Hilt module)
• Medium: Modifying existing logic (adding parameters, new branches)
• High: Changing interfaces, data models, or shared utilities

Step 5: Implementation Phases

Break the work into sequential phases. Each phase should be independently testable and committable.

Phase ordering principle: Foundation → SDK/Data → Network → UI (tests accompany each phase)

For each phase:

Phase Guidelines

• Each phase should be small enough to be independently testable and committable
• Tests are written within the same phase as the code they verify (not deferred to a "testing phase")
• UI phases come after their data dependencies are in place
• If a phase has more than 5 tasks, consider splitting it

Step 6: Risk & Verification

Risk Assessment

Verification Plan

Automated Verification:

• Unit test commands (from build-test-verify skill)
• Lint/detekt commands
• Build verification

Manual Verification:

• [Specific manual test scenarios]
• [Edge cases to manually verify]
• Verify ViewModel state survives process death (test via SavedStateHandle persistence and Don't keep activities developer option)