Feature Builder

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

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

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 File Locations

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

Error Resolution Agents

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

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

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:

Feature Composite Patterns

Higher-level patterns detected by combining individual pattern presence:

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": 23,
  "instinctsAdded": 12
}

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": "feature/auth/domain",
      "files": [
        "model/User.kt",
        "model/AuthToken.kt",
        "repository/AuthRepository.kt",
        "usecase/LoginUseCase.kt",
        "usecase/BiometricAuthUseCase.kt"
      ]
    },
    "data": {
      "path": "feature/auth/data",
      "files": [
        "remote/AuthApi.kt",
        "remote/dto/LoginRequest.kt",
        "remote/dto/LoginResponse.kt",
        "repository/AuthRepositoryImpl.kt",
        "mapper/AuthMapper.kt",
        "local/TokenStorage.kt"
      ]
    },
    "presentation": {
      "path": "feature/auth/presentation",
      "files": [
        "LoginViewModel.kt",
        "LoginState.kt",
        "LoginIntent.kt",
        "LoginSideEffect.kt",
        "ui/LoginScreen.kt",
        "ui/BiometricPromptWrapper.kt"
      ]
    },
    "di": {
      "path": "feature/auth/di",
      "files": [
        "AuthModule.kt"
      ]
    }
  },
  "wiring": {
    "navigationChanges": [
      {
        "file": "app/src/main/java/.../navigation/AppNavGraph.kt",
        "action": "add_route",
        "detail": "Add Login and BiometricPrompt routes"
      }
    ],
    "diRegistration": [
      {
        "file": "app/src/main/java/.../di/AppModule.kt",
        "action": "add_module",
        "detail": "Register authModule in appModules list"
      }
    ],
    "manifestChanges": [
      {
        "file": "app/src/main/AndroidManifest.xml",
        "action": "add_permission",
        "detail": "USE_BIOMETRIC permission"
      }
    ]
  },
  "tests": {
    "unit": [
      "LoginViewModelTest.kt",
      "LoginUseCaseTest.kt",
      "AuthRepositoryImplTest.kt",
      "AuthMapperTest.kt"
    ],
    "ui": [
      "LoginScreenTest.kt",
      "BiometricPromptWrapperTest.kt"
    ],
    "e2e": [
      "AuthFlowE2ETest.kt"
    ]
  },
  "dependencies": {
    "new": [
      { "name": "androidx.biometric:biometric", "version": "1.2.0-alpha05" }
    ],
    "existing": [
      "io.insert-koin:koin-android",
      "io.ktor:ktor-client-core"
    ]
  },
  "tasks": [
    { "id": 1, "phase": "impl", "agent": "architecture-impl", "description": "Create domain models and repository interface", "dependsOn": [] },
    { "id": 2, "phase": "impl", "agent": "network-impl", "description": "Create AuthApi, DTOs, and remote data source", "dependsOn": [1] },
    { "id": 3, "phase": "impl", "agent": "ui-impl", "description": "Create LoginViewModel, State, Intent, and LoginScreen", "dependsOn": [1] },
    { "id": 4, "phase": "impl", "agent": "data-impl", "description": "Create AuthRepositoryImpl, mappers, and TokenStorage", "dependsOn": [2] },
    { "id": 5, "phase": "impl", "agent": "wiring-impl", "description": "Register DI module, add navigation routes, update manifest", "dependsOn": [3, 4] },
    { "id": 6, "phase": "test", "agent": "unit-test-writer", "description": "Write unit tests for ViewModel, UseCase, Repository, Mapper", "dependsOn": [5] },
    { "id": 7, "phase": "test", "agent": "ui-test-writer", "description": "Write Compose UI tests for LoginScreen", "dependsOn": [5] },
    { "id": 8, "phase": "test", "agent": "mobile-e2e-runner", "description": "Write E2E auth flow test", "dependsOn": [5] }
  ]
}

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": {
        "architecture-impl": { "status": "completed", "filesCreated": ["model/User.kt", "model/AuthToken.kt", "repository/AuthRepository.kt"] },
        "network-impl":      { "status": "completed", "filesCreated": ["remote/AuthApi.kt", "remote/dto/LoginRequest.kt"] },
        "ui-impl":           { "status": "completed", "filesCreated": ["LoginViewModel.kt", "ui/LoginScreen.kt"] },
        "data-impl":         { "status": "completed", "filesCreated": ["repository/AuthRepositoryImpl.kt", "mapper/AuthMapper.kt"] },
        "wiring-impl":       { "status": "completed", "filesCreated": ["di/AuthModule.kt"] }
      }
    },
    "3_testing": {
      "status": "completed",
      "startedAt": "2026-03-28T10:12:00Z",
      "completedAt": "2026-03-28T10:15:00Z",
      "agents": {
        "unit-test-writer":  { "status": "completed", "testsCreated": 4 },
        "ui-test-writer":    { "status": "completed", "testsCreated": 2 },
        "mobile-e2e-runner": { "status": "completed", "testsCreated": 1 }
      }
    },
    "4_build_fix": {
      "status": "in_progress",
      "startedAt": "2026-03-28T10:15:00Z",
      "iterations": 2,
      "maxIterations": 5,
      "lastError": "Unresolved reference: BiometricManager",
      "lastFix": "Added missing import for androidx.biometric.BiometricManager"
    },
    "5_quality_gate": {
      "status": "pending",
      "findings": { "critical": 0, "high": 0, "medium": 0, "low": 0 }
    },
    "6_verification": {
      "status": "pending",
      "passAtK": null,
      "coverage": null
    }
  }
}

Status Values

Platform Detection

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

Detection Rules

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

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.

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

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.