llm: Add plan-android-work command and planning skills

.claude/CLAUDE.md

@@ -58,17 +58,23 @@ User Request (UI Action)
 
 ### Workflow Skills
 
-> **Quick start**: Use `/work-on-android <task>` to be guided through the full development lifecycle.
+> **Quick start**: Use `/plan-android-work <task>` to refine requirements and plan,
+> then `/work-on-android <task>` for implementation.
 
-These skills define the full development lifecycle. Use them in order:
+**Planning Phase:**
 
-1. `implementing-android-code` - Patterns, gotchas, and templates for writing code
-2. `testing-android-code` - Test patterns and templates for verifying code
-3. `build-test-verify` - Build, test, lint, and deploy commands
-4. `perform-android-preflight-checklist` - Quality gate before committing
-5. `committing-android-changes` - Commit message format and pre-commit workflow
-6. `reviewing-changes` - Code review checklists for MVVM/Compose patterns
-7. `creating-android-pull-request` - PR creation workflow and templates
+1. `refining-android-requirements` - Gap analysis and structured spec from any input source
+2. `planning-android-implementation` - Architecture design and phased task breakdown
+
+**Implementation Phase:**
+
+3. `implementing-android-code` - Patterns, gotchas, and templates for writing code
+4. `testing-android-code` - Test patterns and templates for verifying code
+5. `build-test-verify` - Build, test, lint, and deploy commands
+6. `perform-android-preflight-checklist` - Quality gate before committing
+7. `committing-android-changes` - Commit message format and pre-commit workflow
+8. `reviewing-changes` - Code review checklists for MVVM/Compose patterns
+9. `creating-android-pull-request` - PR creation workflow and templates
 
 ---
 

.claude/commands/plan-android-work.md

@@ -0,0 +1,119 @@
+---
+description: Guided requirements refinement and implementation planning for Bitwarden Android
+argument-hint: <Jira ticket (PM-12345), Confluence URL, or free-text description>
+---
+
+# Android Planning Workflow
+
+You are guiding the developer through requirements refinement and implementation planning for the Bitwarden Android project. The input to plan from is:
+
+**Input**: $ARGUMENTS
+
+## Prerequisites
+
+- **Jira/Confluence access**: Fetching tickets and wiki pages requires the `bitwarden-atlassian-tools@bitwarden-marketplace` MCP plugin. If the plugin is not installed, Jira ticket IDs and Confluence URLs cannot be fetched automatically.
+
+## Workflow Phases
+
+Work through each phase sequentially. **Confirm with the user before advancing to the next phase.** The user may skip phases that are not applicable. If starting from a partially completed plan, skip to the appropriate phase.
+
+### Phase 1: Ingest Requirements
+
+Parse the input to detect and fetch all available sources:
+
+**Source Detection Rules:**
+- **Jira tickets** (patterns like `PM-\d+`, `BWA-\d+`, `EC-\d+`): Fetch via `get_issue` and `get_issue_comments`. Also fetch linked issue summaries (parent epic, sub-tasks, blockers) for context.
+- **Confluence URLs** (containing `atlassian.net/wiki` or confluence page IDs): Extract page ID and fetch via `get_confluence_page`. If the page is a parent page, fetch child pages via `get_child_pages` and ask the user which are relevant.
+- **Free text**: Treat as direct requirements — no fetching needed.
+- **Multiple inputs**: All are first-class sources. Fetch each independently and consolidate.
+- **Tool unavailable**: If `get_issue`, `get_confluence_page`, or other Atlassian tools are not available, inform the user that the `bitwarden-atlassian-tools@bitwarden-marketplace` MCP plugin is required and prompt them to install and configure it. In the meantime, ask the user to paste the relevant content directly. Treat pasted content as free-text input.
+
+**Present a structured summary:**
+1. Sources identified and fetched (with links)
+2. Raw requirements extracted from each source
+3. Initial scope assessment (small / medium / large)
+
+**Edge cases:**
+- Jira ticket with no description → flag as critical gap that Phase 2 must address
+- Multiple tickets → fetch all, consolidate, flag any contradictions
+- Ticket + free text → both treated as first-class; free text supplements ticket
+
+**Gate**: User confirms the summary is complete and may add additional sources or context before proceeding.
+
+### Phase 2: Refine Requirements
+
+Invoke the `refining-android-requirements` skill and use it to perform gap analysis on the raw requirements from Phase 1.
+
+The skill will:
+1. Consolidate all sources into a working document
+2. Evaluate requirements against a structured rubric (functional, technical, security, UX, cross-cutting)
+3. Present categorized gaps as blocking or non-blocking questions
+4. After user answers, produce a structured specification with numbered IDs
+
+**Gate**: User approves the refined specification. They may request changes or provide additional answers.
+
+### Phase 3: Plan Implementation
+
+Invoke the `planning-android-implementation` skill and use it to design the implementation approach based on the refined spec from Phase 2.
+
+The skill will:
+1. Classify the change type
+2. Explore the codebase for reference implementations and integration points
+3. Design the architecture with component relationships
+4. Produce a file inventory and phased implementation plan
+5. Assess risks and define verification criteria
+
+**Gate**: User reviews the implementation plan and may request changes to architecture, phasing, or scope.
+
+### Phase 4: Finalize & Save
+
+Merge the outputs from Phase 2 (specification) and Phase 3 (implementation plan) into a single design document using this template:
+
+```markdown
+# [Feature Name] — Design Document
+
+**Feature**: [concise description]
+**Date**: [current date]
+**Status**: Ready for Implementation
+**Jira**: [ticket ID if available]
+**Sources**: [list of all input sources with links]
+
+---
+
+## Requirements Specification
+
+[Full output from Phase 2 — the refined specification with numbered IDs]
+
+---
+
+## Implementation Plan
+
+[Full output from Phase 3 — architecture, file inventory, phases, risks]
+
+---
+
+## Executing This Plan
+
+To implement this plan, run:
+
+    /work-on-android [ticket or feature reference]
+
+Reference this design document during implementation for architecture decisions,
+file locations, and phase ordering.
+```
+
+**Save the document:**
+- With ticket: `.claude/outputs/plans/PM-XXXXX-FEATURE-NAME-PLAN.md`
+- Without ticket: `.claude/outputs/plans/FEATURE-NAME-PLAN.md`
+- Feature name should be uppercase with hyphens (e.g., `BIOMETRIC-TIMEOUT-CONFIG-PLAN.md`)
+- Create the output directory if it does not exist
+
+**On completion**: Present the saved file path and remind the user they can execute the plan with `/work-on-android`.
+
+## Guidelines
+
+- Be explicit about which phase you are in at all times.
+- If the user wants to skip a phase, acknowledge and move to the next applicable phase.
+- When fetching from Jira/Confluence, summarize what was found rather than dumping raw content.
+- Questions in Phase 2 should be specific and actionable, not generic.
+- The implementation plan in Phase 3 should reference concrete files in the codebase, not abstract descriptions.

.claude/skills/planning-android-implementation/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: planning-android-implementation
+version: 0.1.0
+description: Architecture design and phased implementation planning for Bitwarden Android. Use when planning implementation, designing architecture, creating file inventories, or breaking features into phases. Triggered by "plan implementation", "architecture design", "implementation plan", "break this into phases", "what files do I need", "design the architecture".
+---
+
+# 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:
+
+| Type | Description | Typical Scope |
+|------|-------------|---------------|
+| **New Feature** | Entirely new functionality, screens, or flows | New files + modifications, multi-phase |
+| **Enhancement** | Extending existing feature with new capabilities | Mostly modifications, 1-2 phases |
+| **Bug Fix** | Correcting incorrect behavior | Targeted modifications, single phase |
+| **Refactoring** | Restructuring without behavior change | Modifications only, migration-aware |
+| **Infrastructure** | Build, CI, tooling, or dependency changes | Config files, minimal code changes |
+
+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
+┌────────▼────────┐
+│   ViewModel     │ ← Business logic orchestration
+└────────┬────────┘
+         │ Repository calls
+┌────────▼────────┐
+│   Repository    │ ← Data coordination (sealed class results)
+└───┬────┬────┬───┘
+    │    │    │
+┌───▼───┐ │ ┌─▼──────┐
+│Manager│ │ │Manager │ ← Single-responsibility (optional)
+└───┬───┘ │ └─┬──────┘
+    │     │   │
+┌───▼─────▼───▼────┐
+│   Data Sources   │ ← Raw data (Result<T>, never throw)
+└─┬────┬────┬──────┘
+  │    │    │
+ Room Retrofit SDK
+```
+
+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:
+
+| Decision | Resolution | Rationale |
+|----------|-----------|-----------|
+| [What needed deciding] | [What was chosen] | [Why] |
+
+---
+
+## Step 4: File Inventory
+
+### Files to Create
+
+| File Path | Type | Pattern Reference |
+|-----------|------|-------------------|
+| [full path] | [ViewModel / Screen / Repository / etc.] | [pattern anchor file] |
+
+**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
+
+| File Path | Change Description | Risk Level |
+|-----------|-------------------|------------|
+| [full path] | [what changes] | Low / Medium / High |
+
+**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:
+
+```markdown
+### Phase N: [Name]
+
+**Goal**: [What this phase accomplishes]
+
+**Files**:
+- Create: [list]
+- Modify: [list]
+
+**Tasks**:
+1. [Specific implementation task]
+2. [Specific implementation task]
+3. ...
+
+**Verification**:
+- [Test command or manual verification step]
+
+**Skills**: [Which workflow skills apply — e.g., `implementing-android-code`, `testing-android-code`]
+```
+
+### 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
+
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| [What could go wrong] | Low/Med/High | Low/Med/High | [How to prevent or handle] |
+
+### 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)