feature-builder

name	feature-builder
description	End-to-end mobile feature builder. Takes a feature from description to fully running code with E2E tests through six phases - planning, architecture review, implementation, testing, build-fix, quality gate, and verification. Supports Android, iOS, and KMP with platform auto-detection. Use when this capability is needed.
metadata	{"author":"ahmed3elshaer"}

Feature Builder Skill

Zero-to-feature orchestration pipeline for mobile development. Transforms a feature description into production-ready code through six structured phases with automated agent coordination, build verification, and quality enforcement.

Overview

The feature builder runs a deterministic six-phase pipeline:

Phase 1: Planning          Phase 2: Implementation       Phase 3: Testing
 ┌────────────┐             ┌────────────────┐            ┌──────────────┐
 │ Plan + Arch│────────────▶│ 5-Agent DAG    │───────────▶│ 3 Test Agents│
 │   Review   │             │  Build Code    │            │  in Parallel │
 └────────────┘             └────────────────┘            └──────────────┘
        │                                                        │
        ▼                                                        ▼
Phase 6: Verification      Phase 5: Quality Gate          Phase 4: Build & Fix
 ┌────────────┐             ┌────────────────┐            ┌──────────────┐
 │ pass@k=3   │◀────────────│ 3 Reviewers    │◀───────────│ Compile/Test │
 │ Coverage   │             │  in Parallel   │            │  Fix Loop    │
 └────────────┘             └────────────────┘            └──────────────┘

Entry Points:

• /feature-build <description> -- Full pipeline from planning to verification
• /feature-build --from-phase=<N> -- Resume from a specific phase
• /feature-build --skip-phase=<N> -- Skip a phase (e.g., skip quality gate for prototypes)
• Individual phase commands for targeted execution

Supported Platforms: Android, iOS, KMP (auto-detected or explicit via --platform)

---

Usage

Full Pipeline

# Auto-detect platform, run all phases
/feature-build "User authentication with biometric login"

# Explicit platform
/feature-build --platform=android "Shopping cart checkout flow"
/feature-build --platform=ios "Push notification preferences"
/feature-build --platform=kmp "Offline-first data sync"

Partial Execution

# Resume from implementation (plan already exists)
/feature-build --from-phase=2 --feature=auth

# Skip quality gate for rapid prototyping
/feature-build --skip-phase=5 "Quick settings screen"

# Run only a single phase
/feature-plan "User profile editor"
/feature-implement --feature=profile-editor
/feature-test --feature=profile-editor

Flags

Flag	Description	Default
--platform	Target platform: android, ios, kmp	Auto-detect
--from-phase	Start from phase N (1-6)	1
--skip-phase	Comma-separated phases to skip	None
--feature	Feature name (for resuming)	Derived from description
--force	Reset and re-run current phase	false
--dry-run	Generate plan only, no implementation	false

---

Phase 1: Planning (/feature-plan)

Creates a comprehensive plan document and validates it through architecture review.

Workflow

User Description
       │
       ▼
┌──────────────────┐     ┌───────────────────┐     ┌─────────────┐
│ feature-planner  │────▶│ mobile-architect   │────▶│ User Review │
│ (create plan)    │     │ (critique plan)    │     │ (approve)   │
└──────────────────┘     └───────────────────┘     └─────────────┘

Steps

1. Platform Detection -- Scan project for platform markers (see Platform Detection)
2. Codebase Analysis -- feature-planner agent reads project structure, existing modules, DI setup, navigation graph, and version catalog
3. Plan Generation -- Produces .omc/plans/feature-{name}.json with module breakdown, file list, dependency graph, and task ordering
4. Architecture Review -- mobile-architect agent (model: opus) critiques the plan for:
   • Layer separation violations
   • Missing error handling paths
   • Navigation integration gaps
   • DI registration completeness
   • Naming convention adherence
5. Revision -- Planner incorporates architect feedback
6. User Approval -- Present plan summary; user approves, requests changes, or cancels

Checkpoint

Checkpoint: after-plan-{featureName}
Contents: plan document, platform detection results, codebase analysis

---

Phase 2: Implementation (/feature-implement)

Executes a five-agent dependency DAG to build the feature layer by layer.

Agent DAG

         ┌─────────────────────┐
         │  architecture-impl  │   Phase 2a: Domain layer
         │  (domain models,    │   - Models, repository interfaces
         │   use cases, repo   │   - Use cases with Result<T>
         │   interfaces)       │   - Domain exceptions
         └──────────┬──────────┘
                    │
           ┌────────┴────────┐
           ▼                 ▼
  ┌─────────────────┐  ┌─────────────────┐
  │   network-impl  │  │     ui-impl     │   Phase 2b: Parallel
  │   (API client,  │  │   (Composables, │   - Network + UI run
  │    DTOs, remote │  │    Screens,     │     simultaneously
  │    data source) │  │    ViewModels,  │   - Both read plan for
  └────────┬────────┘  │    States,      │     file locations
           │           │    Intents)     │
           │           └─────────────────┘
           ▼
  ┌─────────────────┐
  │    data-impl    │   Phase 2c: Data layer
  │  (Repository    │   - Needs network DTOs
  │   impl, mappers,│   - Implements domain interfaces
  │   local cache)  │   - Mapper functions
  └────────┬────────┘
           │
           ▼
  ┌─────────────────┐
  │   wiring-impl   │   Phase 2d: Integration
  │  (DI modules,   │   - Koin/Hilt module registration
  │   navigation,   │   - Navigation graph updates
  │   manifest)     │   - AndroidManifest changes (if any)
  └─────────────────┘

Execution Rules

• Each agent reads from .omc/plans/feature-{name}.json for its file list and module paths
• Agents write only to their designated files (enforced by plan document)
• network-impl and ui-impl run in parallel since they have no mutual dependency
• data-impl waits for network-impl (needs DTOs for mapping)
• wiring-impl runs last to connect all layers
• All agents respect the project's existing patterns (read from mobile-memory MCP)

Platform-Specific Behavior

Platform	Domain	Network	UI	Data	Wiring
Android	Kotlin data classes	Retrofit/Ktor	Compose + ViewModel	Room/DataStore	Koin/Hilt + Navigation
iOS	Swift structs	URLSession/Alamofire	SwiftUI + ObservableObject	CoreData/SwiftData	Dependency container + NavigationStack
KMP	commonMain models	Ktor (shared)	Compose Multiplatform / SwiftUI	SQLDelight	Koin + expect/actual navigation

Checkpoint

Checkpoint: after-impl-{featureName}
Contents: all generated source files, updated DI modules, navigation changes

---

Phase 3: Testing (/feature-test)

Three test-writing agents run in parallel, each reading the plan's test section.

Agents

┌───────────────────┐  ┌───────────────────┐  ┌───────────────────┐
│  unit-test-writer  │  │  ui-test-writer   │  │ mobile-e2e-runner │
│                   │  │                   │  │                   │
│ - ViewModel tests │  │ - Screen tests    │  │ - Flow tests      │
│ - UseCase tests   │  │ - Component tests │  │ - Integration     │
│ - Repository tests│  │ - Navigation tests│  │ - Happy path      │
│ - Mapper tests    │  │ - Snapshot tests  │  │ - Error paths     │
└───────────────────┘  └───────────────────┘  └───────────────────┘

Test Coverage Targets

Test Type	Minimum Coverage	Agent
Unit tests	80% line coverage	unit-test-writer
UI tests	All screens + key interactions	ui-test-writer
E2E tests	Happy path + top 3 error paths	mobile-e2e-runner

Test File Locations

Platform	Unit Tests	UI Tests	E2E Tests
Android	src/test/java/...	src/androidTest/java/...	src/androidTest/java/.../e2e/
iOS	Tests/{Feature}Tests/	UITests/{Feature}UITests/	UITests/{Feature}E2ETests/
KMP	src/commonTest/...	Platform-specific androidTest/iosTest	Platform-specific

Checkpoint

Checkpoint: after-test-{featureName}
Contents: all test files, test configuration changes

---

Phase 4: Build & Fix (/feature-build-fix)

Iterative compile-test-fix loop that resolves build errors and test failures.

Loop

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Compile    │────▶│  Analyze     │────▶│    Fix       │
│              │     │  Errors      │     │              │
└──────┬───────┘     └──────────────┘     └──────┬───────┘
       │                                         │
       │         ┌──────────────┐                │
       │         │  Run Tests   │                │
       │         └──────┬───────┘                │
       │                │                        │
       ▼                ▼                        ▼
  ┌─────────────────────────────────────────────────┐
  │              All Green?                          │
  │  YES ──▶ Proceed to Phase 5                     │
  │  NO  ──▶ Iteration++ (max 5)                    │
  │  MAX  ──▶ Escalate to user with diagnostics     │
  └─────────────────────────────────────────────────┘

Build Commands by Platform

Platform	Compile	Unit Tests	UI Tests
Android	./gradlew assembleDebug	./gradlew test	./gradlew connectedAndroidTest
iOS	xcodebuild build	xcodebuild test	xcodebuild test -testPlan UITests
KMP	./gradlew build	./gradlew allTests	Platform-specific

Error Resolution Agents

Platform	Agent	Specialization
Android	android-build-resolver	Gradle, Kotlin compiler, resource errors
iOS	xcode-build-resolver	Xcode, Swift compiler, linker errors
KMP	Both (routed by error source)	Shared + platform-specific errors

Iteration Limits

• Max iterations: 5
• Per-iteration timeout: 3 minutes
• Escalation: After 5 failed iterations, pause and present:
  • Full error log from last iteration
  • Summary of attempted fixes
  • Suggested manual interventions
  • Option to --force reset the phase

Checkpoint

Checkpoint: after-build-fix-{featureName}
Contents: compiled artifacts, fixed source files, build logs

---

Phase 5: Quality Gate (/feature-quality-gate)

Three review agents run in parallel to assess code quality, security, and performance.

Reviewers

┌───────────────────────┐  ┌──────────────────────────┐  ┌────────────────────────────────┐
│   android-reviewer    │  │ mobile-security-reviewer  │  │ mobile-performance-reviewer    │
│   (or ios-reviewer)   │  │                          │  │                                │
│                       │  │ - Hardcoded secrets      │  │ - Memory leaks                 │
│ - Code style          │  │ - Insecure storage       │  │ - Unnecessary recomposition    │
│ - Architecture        │  │ - Network security       │  │ - Blocking main thread         │
│ - Error handling      │  │ - Input validation       │  │ - Large allocations            │
│ - Naming conventions  │  │ - Logging exposure       │  │ - N+1 queries                  │
│ - Dead code           │  │ - Permission usage       │  │ - Image loading efficiency     │
└───────────┬───────────┘  └────────────┬─────────────┘  └───────────────┬────────────────┘
            │                           │                                │
            └───────────────┬───────────┘                                │
                            │◀───────────────────────────────────────────┘
                            ▼
                   ┌────────────────┐
                   │ Collect & Triage│
                   │  Findings      │
                   └────────┬───────┘
                            │
                   ┌────────▼───────┐
                   │ Apply Fixes    │
                   │ (auto for low) │
                   └────────┬───────┘
                            │
                   ┌────────▼───────┐
                   │ Re-verify      │
                   │ Critical Items │
                   └────────────────┘

Finding Severity Levels

Severity	Action	Example
Critical	Block release, fix immediately	Hardcoded API key, SQL injection
High	Must fix before merge	Missing error handling, memory leak
Medium	Should fix, auto-applied when possible	Naming convention violation, missing null check
Low	Informational, auto-applied	Import ordering, trailing whitespace

Gate Pass Criteria

• Zero critical findings
• Zero high findings (or user-acknowledged exceptions)
• All medium findings addressed or explicitly deferred
• Re-verification passes for any critical/high fixes applied

Checkpoint

Checkpoint: after-quality-gate-{featureName}
Contents: review reports, applied fixes, acknowledged deferrals

---

Phase 6: Verification (/feature-verify)

Final sign-off with pass@k reliability testing and coverage enforcement.

Process

1. pass@k=3 Testing -- mobile-verifier agent runs all feature tests 3 times
2. Flaky Detection -- Identify tests with pass@k < 1.0
3. Coverage Check -- Enforce >= 80% line coverage on new code
4. Report Generation -- Produce final verification report

Acceptance Criteria

Metric	Threshold	Action if Failed
Unit test pass@3	>= 0.95	Fix flaky tests, re-run
UI test pass@3	>= 0.80	Investigate, fix or quarantine
E2E test pass@3	>= 0.60	Investigate root cause
Line coverage	>= 80%	Add missing tests
Critical findings	0	Return to Phase 5

Final Report

Feature: {featureName}
Platform: {platform}
Status: PASSED / FAILED

Phase Results:
  1. Planning .............. COMPLETED
  2. Implementation ........ COMPLETED (5 agents, 23 files)
  3. Testing ............... COMPLETED (14 unit, 6 UI, 3 E2E)
  4. Build & Fix ........... COMPLETED (2 iterations)
  5. Quality Gate .......... COMPLETED (0 critical, 1 medium fixed)
  6. Verification .......... COMPLETED (pass@3=0.96, coverage=84%)

Files Created: 23
Tests Written: 23
Build Iterations: 2
Duration: ~18 minutes

Checkpoint

Checkpoint: feature-complete-{featureName}
Contents: full verification report, final metrics, all source + test files

---

Phase 7: Learning (/feature-learn)

Automatic pattern extraction and continuous learning. Runs immediately after Phase 6 verification completes -- no separate invocation needed.

Process

Phase 6 PASSED
       |
       v
+-----------------------+     +------------------------+     +---------------------+
| Scan Generated Files  |---->| Extract Mobile Patterns|---->| Detect Feature      |
| (from plan manifest)  |     | (17 pattern matchers)  |     | Composite Patterns  |
+-----------------------+     +------------------------+     +---------------------+
                                                                      |
                                                                      v
+---------------------+     +------------------------+     +---------------------+
| Save Learning       |<----| Calculate Completeness |<----| Store as Instincts  |
| Summary Report      |     | Score (weighted)       |     | (with confidence)   |
+---------------------+     +------------------------+     +---------------------+

Pattern Extraction

The learning phase scans all generated feature files for established mobile patterns:

Category	Patterns Detected	Context Tag
Compose	State hoisting, lazy keys, immutable data classes	jetpack-compose
MVI	Intent handling, sealed state/intent/side-effect	mvi-architecture
DI	Koin module definition, ViewModel injection	koin-patterns
Network	Safe Ktor requests with runCatching	ktor-patterns
Coroutines	Structured concurrency with viewModelScope	coroutines-patterns
Clean Architecture	Repository interface/impl, use cases, mappers, Result type	clean-architecture
Navigation	Compose Navigation route registration	navigation-patterns

Feature Composite Patterns

Higher-level patterns detected by combining individual pattern presence:

Pattern ID	Criteria	Weight
feature-clean-architecture	Domain + Data + Presentation layers all present (repository interface, impl, and use case detected)	25%
feature-mvi-complete	State + Intent + SideEffect sealed interfaces + ViewModel with viewModelScope	25%
feature-di-complete	Koin module definition + ViewModel injection present	15%
feature-test-coverage	Unit + UI + E2E test files all present in plan	20%
feature-navigation-wired	Navigation route registered in navigation graph	15%

Confidence Scoring

• Individual patterns start at confidence 0.5 (higher than session-detected patterns at 0.4, since feature builds are more deliberate)
• Each subsequent detection of the same pattern increases confidence by 0.1 (capped at 1.0)
• Composite feature patterns start at 0.5-0.6 based on complexity
• Unused instincts decay by 0.05 after 30 days of inactivity

Completeness Score

The feature completeness score is a weighted sum (0-100%) of the five composite patterns:

Score = (clean_arch * 25) + (mvi_complete * 25) + (di_complete * 15)
      + (test_coverage * 20) + (navigation_wired * 15)

Score >= 80%  -->  High quality feature build
Score 50-79%  -->  Acceptable, some patterns missing
Score < 50%   -->  Needs improvement, review missing layers

Learning Output

Saved to .omc/state/feature-{name}-learning.json:

{
  "featureName": "auth",
  "platform": "android",
  "learnedAt": "2026-03-28T10:20:00Z",
  "patternsDetected": ["sealed-interface-state", "mvi-intent-handling", "..."],
  "featurePatterns": {
    "feature-clean-architecture": true,
    "feature-mvi-complete": true,
    "feature-di-complete": true,
    "feature-test-coverage": true,
    "feature-navigation-wired": true
  },
  "completenessScore": 100,
  "filesScanned" 
   

Feedback Loop

Learned patterns feed back into the instinct system:

• Future /feature-build runs consult high-confidence instincts when generating plans
• Patterns with confidence >= 0.7 are treated as established project conventions
• The /feature-learn command shows accumulated learning across all feature builds
• Instincts can be exported via /instinct-export for sharing across projects

Checkpoint

Checkpoint: feature-learning-{featureName}
Contents: learning summary, updated instincts, completeness score

---

Plan Document Schema

Plan documents are stored at .omc/plans/feature-{name}.json.

{
  "featureName": "auth",
  "description": "User authentication with email/password and biometric login",
  "platform": "android",
  "createdAt": "2026-03-28T10:00:00Z",
  "updatedAt": "2026-03-28T10:15:00Z",
  "architecture": {
    "pattern": "MVI",
    "diFramework": "Koin",
    "networkClient": "Ktor",
    "localStorage": "DataStore",
    "navigationLib": "Compose Navigation"
  },
  "moduleLocation": "feature/auth",
  "modules": {
    "domain": {
      "path" 
       
        
        
        
        
        
      
    
     
       
       
        
        
        
        
        
        
      
    
     
       
       
        
        
        
        
        
        
      
    
     
       
       
        
      
    
  
   
     
      
         
         
         
      
    
     
      
         
         
         
      
    
     
      
         
         
         
      
    
  
   
     
      
      
      
      
    
     
      
      
    
     
      
    
  
   
     
           
    
     
      
      
    
  
   
               
               
               
               
                
               
               
               
  

---

State File Schema

State files are stored at .omc/state/feature-{name}.json and track real-time progress.

{
  "featureName": "auth",
  "platform": "android",
  "startedAt": "2026-03-28T10:00:00Z",
  "currentPhase": 4,
  "phases": {
    "1_planning": {
      "status": "completed",
      "startedAt": "2026-03-28T10:00:00Z",
      "completedAt": "2026-03-28T10:05:00Z",
      "planPath": ".omc/plans/feature-auth.json"
    },
    "2_implementation": {
      "status": "completed",
      "startedAt": "2026-03-28T10:05:00Z",
      "completedAt": "2026-03-28T10:12:00Z",
      "agents" 
                
                    
                         
                       
                    
      
    
     
       
       
       
       
               
                 
              
      
    
     
       
       
       
       
       
       
    
     
       
                
    
     
       
       
       
    
  

Status Values

Status	Meaning
pending	Phase not yet started
in_progress	Phase currently executing
completed	Phase finished successfully
failed	Phase failed, requires intervention
skipped	Phase skipped via --skip-phase flag

---

Platform Detection

Auto-detection scans the project root for platform markers. First match wins.

Detection Rules

Platform	Primary Marker	Secondary Marker	Tertiary Marker
KMP	shared/src/commonMain/ directory	build.gradle.kts with kotlin("multiplatform")	composeApp/ directory
Android	build.gradle.kts or build.gradle at root	app/src/main/AndroidManifest.xml	settings.gradle.kts with Android modules
iOS	*.xcodeproj or *.xcworkspace	Package.swift	*.pbxproj file

Detection Priority

1. Check for shared/src/commonMain/ → KMP
2. Check for *.xcodeproj or *.xcworkspace → iOS
3. Check for build.gradle.kts with android block → Android
4. Prompt user if ambiguous

Override

# Force platform when auto-detection is wrong
/feature-build --platform=kmp "Feature description"

---

Error Recovery

Every phase creates a checkpoint before execution. On failure, the pipeline can resume from the last successful state.

Recovery Commands

# Resume from where it left off (reads state file)
/feature-build --from-phase=auto --feature=auth

# Force re-run a specific phase (resets that phase's state)
/feature-build --from-phase=4 --force --feature=auth

# View current state
cat .omc/state/feature-auth.json

Recovery Strategy

Failure Point	Recovery Action
Phase 1 fails	Re-run planning from scratch
Phase 2 agent fails	Re-run only the failed agent + its dependents
Phase 3 test writer fails	Re-run only the failed test agent
Phase 4 exceeds max iterations	Present diagnostics, user chooses fix or skip
Phase 5 critical finding	Apply fix, re-run Phase 4 then Phase 5
Phase 6 coverage below 80%	Return to Phase 3 for additional tests

State File Integrity

• State file is written atomically (write to temp, then rename)
• Each phase reads the previous phase's state before starting
• Corrupted state file triggers a full checkpoint restore
• --force flag resets a single phase's state to pending

---

Phase Commands

Each phase can be invoked independently for targeted execution.

Command	Phase	Description	Prerequisite
/feature-plan <desc>	1	Create and review plan	None
/feature-implement	2	Run 5-agent implementation DAG	Plan exists
/feature-test	3	Run 3 test-writing agents	Implementation complete
/feature-build-fix	4	Iterative compile/test/fix loop	Tests written
/feature-quality-gate	5	Run 3 review agents	Build passing
/feature-verify	6	pass@k testing + coverage	Quality gate passed
/feature-build <desc>	1-6	Full pipeline	None

Common Workflows

# Full feature from scratch
/feature-build "Payment processing with Stripe"

# Already have a plan, just implement
/feature-implement --feature=payments

# Code exists, need tests and verification
/feature-build --from-phase=3 --feature=payments

# Quick iteration: fix build and re-verify
/feature-build-fix --feature=payments && /feature-verify --feature=payments

---

Integration

Mobile Memory MCP

The feature builder reads and writes to mobile-memory for cross-session context:

• Reads: Project architecture patterns, existing module structure, DI conventions, naming patterns, test patterns
• Writes: New feature metadata, file manifest, dependency additions, learned patterns from build-fix iterations

Checkpoint System

Integrates with the mobile-checkpoint skill:

• Auto-creates checkpoints at each phase boundary
• Naming convention: {phase-name}-{featureName} (e.g., after-impl-auth)
• Full checkpoint at feature completion: feature-complete-{featureName}
• Checkpoints include instinct snapshots for rollback safety

Instinct Hooks

The feature builder triggers instinct learning:

• Phase 2 patterns: Architecture decisions, file organization choices
• Phase 4 patterns: Common build errors and their fixes per project
• Phase 5 patterns: Recurring code review findings
• Instincts are versioned per feature so rollback does not lose learning

Hook Events

Hook Point	Event	Data
PreToolUse	Phase start	Phase number, feature name, platform
PostToolUse	Phase complete	Phase number, status, metrics
PostToolUse	Build iteration	Iteration count, error summary
PostToolUse	Quality finding	Severity, category, file path

---

Remember: The feature builder is a pipeline, not a monolith. Each phase is independently testable, resumable, and skippable. Trust the DAG -- let agents work in parallel where dependencies allow, and checkpoint aggressively so no work is ever lost.

---

Source: ahmed3elshaer/everything-claude-code-mobile — distributed by TomeVault.