--- description: "🚀 Full-autonomous product build from Android reference, app name, or idea" --- # /autobuild — Autonomous Product Builder > **One prompt in → validated MVP out.** > > MVP sources: an Android package/APK, an app name, or a product topic. Android > references are analysed locally; iOS apps are always included in the market and > UX review. The workflow runs autonomously after intake and only surfaces a final > report or a decision that cannot be recovered automatically. --- ## Usage ```text /autobuild "com.example.android" /autobuild "Duolingo-style language practice for office workers" --target expo --market VN /autobuild "reference-app.apk" --target kotlin-compose /autobuild "a shared family budget app" --target swift ``` ### Input contract | Input | Detection | Discovery action | |---|---|---| | Android package | Reverse-domain package pattern | `justapk download` → XAPK conversion when needed → decompile | | APK/XAPK path | Existing supported archive | Decompile directly | | App name | Product name without a package/path | Locate Android and iOS listings; analyse public product behaviour | | Product topic | Free-form problem statement | Start problem discovery and market research | ### Defaults ```yaml execution: full-autonomous target_stack: kotlin-compose # override: swift | expo market: global reference_mode: clean-room-inspired max_recovery_attempts: 3 ``` `clean-room-inspired` means reproduce user problems, observable flows, and product-level lessons—not source code, embedded secrets, brands, paid assets, or proprietary server access. --- ## Operating rules 1. Do not ask routine discovery, stack, or approval questions. Infer sensible defaults and record them in the assumptions ledger. 2. Continue after recoverable tool, agent, or research failures using the best available evidence; log the fallback and affected confidence level. 3. Android references provide implementation evidence. iOS references provide mandatory competitive, UX, monetisation, and platform-convention evidence. 4. Treat extracted endpoints as observations only. Never copy credentials, tokens, signing material, proprietary APIs, or source code into the new app. 5. Every implementation task must have explicit inputs, owned files, acceptance criteria, verification command, dependency IDs, and an artifact path. 6. A failed quality gate produces remediation tasks and retries automatically; only an unresolved blocking external dependency may pause the run. --- ## Autonomous pipeline ### Phase 0 — Create the venture workspace Create a session namespace and preserve every artifact: ```text brain//autobuild// docs/autobuild// ``` Write `00-intake.md` containing the raw prompt, detected source type, selected stack, market, assumptions, and recovery log. Create a Symphony root task with child phases below. ### Phase 1 — Reference and product discovery #### Android package or APK/XAPK 1. For a package, download with `justapk download -o `. 2. Convert split/XAPK artifacts with `justapk convert` when required. 3. Run `android-re-analyzer/scripts/check-deps.sh`; install only required dependencies when the environment permits, then re-check. 4. Decompile using `android-re-analyzer/scripts/decompile.sh`; use `--deobf` when identifiers are obfuscated and `--engine both` if JADX warnings prevent reliable interpretation. 5. Analyse manifest, entry points, navigation, resources, domain concepts, persistence, observable state transitions, and public network contracts. 6. Produce evidence-backed—not inferred—findings in: ```text 01-android-reference.md 02-feature-inventory.md 03-user-flow-map.md 04-screen-catalog.md 05-domain-and-state-map.md 06-observed-api-contracts.md 07-reference-design-language.md ``` #### App name or product topic 1. Resolve the intended app/name from public listings and cite the confidence. 2. Map the job-to-be-done, target audience, onboarding, core loop, retention loop, feature inventory, and monetisation model. 3. If identity is ambiguous, choose the highest-confidence candidate and record the alternatives instead of blocking the run. ### Phase 2 — Cross-platform market and iOS review Run the `radar-research` health check before collecting data. Use its packaged wrappers for top charts, competitor metadata/reviews, and community research. Research must include: - Android reference or direct Android competitors; - at least two iOS competitors or category leaders, unless the category has no credible iOS listing (record this evidence); - review themes, complaints, retention triggers, price/paywall patterns, and platform-specific expectations; - direct and indirect competitors plus a differentiated opportunity thesis. Store: ```text 08-market-landscape.md 09-competitor-matrix.md 10-voice-of-customer.md 11-ios-product-and-ux-review.md 12-opportunity-thesis.md ``` ### Phase 3 — Feasibility spike and MVP boundary Identify the highest-risk assumptions, then implement the smallest disposable spikes necessary to validate them. Typical spikes cover device APIs, AI/OCR, offline sync, third-party integrations, performance, cost, or a critical UI interaction. Define a single end-to-end **aha moment** and cut all non-essential reference features from MVP. Capture: ```text 13-risk-register.md 14-spike-results.md 15-cost-model.md 16-mvp-boundary.md 17-go-no-go.md ``` Autonomous decision rule: - **GO:** no unmitigated blocker and the aha flow is feasible. - **PIVOT:** reduce/reframe scope and rerun the affected spike. - **BLOCKED:** create a Symphony blocker task with evidence only after three materially different recovery attempts fail. ### Phase 4 — Product, design, architecture, and estimate package Generate a self-contained delivery baseline: ```text 18-prd.md 19-user-stories-and-acceptance.md 20-architecture.md 21-data-and-api-contracts.md 22-design-system.md 23-delivery-plan.md 24-estimates.md 25-quality-and-parity-strategy.md 26-release-plan.md ``` #### Target-stack rules | Target | Default implementation direction | |---|---| | `kotlin-compose` | Kotlin, Jetpack Compose, modern Android architecture; select minimal data/DI dependencies only when justified | | `swift` | Swift/SwiftUI with native platform conventions and equivalent iOS UX review findings | | `expo` | Expo/React Native, TypeScript, native modules only where the aha flow requires them | Estimate by outcomes, dependencies, and uncertainty—not raw feature counts: | Phase | Outcome | Exit criterion | |---|---|---| | 0 | Discovery evidence | Reference/market dossier has confidence labels | | 1 | Feasibility | Critical spikes prove or narrow the solution | | 2 | Foundation | Build, navigation, design tokens, and test baseline work | | 3 | Core MVP | Aha flow succeeds end-to-end | | 4 | Beta quality | Loading/empty/error/offline/accessibility paths verified | | 5 | Release | Release checklist, observability, and handover complete | ### Phase 5 — Leo plan review (hard gate) Invoke the reasoning role; never resolve `leo` to a fixed model: ```bash awkit exec -r reasoning -t 300 "Review docs/autobuild//18-prd.md through 26-release-plan.md. Challenge MVP scope, risks, architecture, estimates, testability, Android-reference assumptions, and mandatory iOS comparison. Return blockers, required fixes, and a pass/fail verdict." ``` Save the response as `27-leo-plan-review.md`. If it fails, create targeted remediation tasks, revise the package, and repeat the review up to three times. If it still fails, proceed only with the highest-confidence reduced MVP and record each unresolved risk in `17-go-no-go.md`. ### Phase 6 — Symphony task graph and delegated execution Create task waves, not one oversized task: ```text Wave A: project foundation, design system, data/API boundaries, test harness Wave B: independent vertical MVP slices Wave C: end-to-end integration and recovery paths Wave D: accessibility, visual parity, security, performance, release readiness ``` Routing guide: | Work | Preferred role | |---|---| | Architecture, difficult domain logic, audits | `leo` / reasoning role | | UI implementation and visual verification | designer-capable runner | | Local, bounded implementation | cost-optimised runner | | Build, test, regression verification | research/verification runner | Before coding, each execution agent reads only the relevant baseline sections and upstream artifact paths. It must return changed files, test evidence, unresolved risks, and the task artifact. ### Phase 7 — Continuous verification and final review After each wave: 1. Run targeted tests and build checks. 2. Compare implemented behaviour to `19-user-stories-and-acceptance.md`. 3. Verify Android behavioural evidence where applicable. 4. Verify iOS UX/platform findings from `11-ios-product-and-ux-review.md`, even when the target is Android or Expo. 5. Create repair tasks for failures and run the next eligible tasks. Final artifacts: ```text 28-implementation-summary.md 29-verification-report.md 30-known-limitations.md 31-handover-and-next-roadmap.md ``` --- ## Completion contract Report only when one of these is true: - **Completed:** MVP builds, the aha flow passes, required verification evidence exists, and all remaining items are explicitly deferred. - **Blocked:** three recovery attempts cannot overcome an external dependency; include exact evidence, attempted recovery paths, and the smallest user action needed to resume. The final status includes: selected stack, source evidence confidence, iOS review coverage, MVP scope, phase estimates, task results, build/test evidence, known limitations, and the exact artifact directory. --- ## Existing AWKit building blocks ```text /decompile + android-re-analyzer Android acquisition and evidence extraction radar-research Market, competitor, and review research /brainstorm + /plan Product framing and specifications awkit exec -r reasoning Leo plan review Symphony + /auto-implement Dependency-aware delegated execution verification/review workflows Quality and release evidence ```