A coordinated team of 53 Claude Code subagents that build, ship, and operate mobile apps end to end. Each agent owns a narrow slice of the lifecycle so that responsibility, expertise, and review checkpoints stay separated and observable.
Brownfield onboarding for an existing mobile-app codebase. Audits PRDs, ADRs, stories, UX specs, and architecture docs for compatibility with this template's review skills, classifies gaps by impact, and produces a numbered migration plan. Use when joining a project mid-flight or upgrading from an older template…
Creates an Architecture Decision Record (ADR) documenting a significant technical decision — its context, alternatives, decision, consequences, and PRD requirements addressed. Every major mobile-architecture choice should have an ADR. Framework-version-aware: cross-references the framework reference docs to flag…
Validates the architecture against all PRDs. Builds a traceability matrix from PRD requirements to ADRs, identifies coverage gaps, detects cross-ADR conflicts, and produces a PASS/CONCERNS/FAIL verdict. Run after Required ADRs are written; rerun whenever PRDs change. Read-only — never edits files.
Audits app assets for naming conventions, file size budgets, format standards, app icon completeness, splash screens, and store-listing imagery. Identifies orphans (asset on disk but never referenced) and missing references (referenced but missing).
Generates per-asset visual specifications and AI-generation prompts from PRDs and the design bible. Produces structured spec files and updates a master asset manifest. Use after design bible is approved and a UX spec or PRD identifies assets to produce. Output: design/assets/ .md plus design/assets/manifest.md.
Analyze pricing tiers, paywall configs, A/B test variants, and feature-flag values for outliers, broken funnels, dominant variants, and monetization imbalance. Use after editing pricing, paywall copy, or any growth-experiment config.
Guided ideation for a mobile app — from a blank page (or a single hint) to a structured concept doc covering target user, core job-to-be-done, MVP scope, and primary metric. Use when starting a new app or when an existing pitch needs to be tightened into a concept.
Author a structured bug report from a description, OR analyze code/logs to derive likely bugs. Captures reproduction steps, severity, device matrix, expected vs actual, and attachments. Use after a manual QA failure or when the user describes a defect.
Read all open bugs, re-evaluate priority and severity, surface systemic trends, and assign each to a sprint or backlog. Run at sprint start or when the open bug count grows beyond comfort.
Auto-generate a changelog from git commits, sprint data, and design docs. Produces both internal (engineering-facing) and user-facing (release-notes) versions for a given release window.
Architectural and quality review of one or more files. Verifies coding standards, SOLID, testability, mobile anti-patterns, and ADR compliance. Use after /dev-story and before /story-done.
Read-only audit that scans all PRDs against the entity registry and detects cross-doc inconsistencies — same entity with different values, same configurable value with different defaults, same formula with different variables. Use when multiple PRDs are in flight to catch drift before /review-all-prds runs.
Audits PRD-specified content counts (screens, copy strings, images, supported locales, push categories, onboarding steps) against what is actually implemented. Identifies what is planned vs. what is built. Read-only.
Section-by-section authoring of the master architecture doc for the app. Reads all PRDs, systems index, existing ADRs, and the framework reference docs to produce a complete blueprint and a Required ADR list. Framework-version-aware: flags knowledge gaps and validates against the pinned framework. Run after…
Produces a flat, immediately-actionable rules sheet — do this, never do that, per system and per layer — extracted from accepted ADRs, technical preferences, and framework reference docs. More directly usable than ADRs for day-to-day implementation. Run after /architecture-review passes.
Translates approved PRDs and architecture into epics — one epic per architectural module or major system. Each epic captures scope, governing ADRs, framework risk, and untraced requirements. Run after /architecture-review passes; do NOT decompose into stories — run /create-stories per epic afterward.
Decomposes a single epic into implementable story files. Each story embeds its TR-ID, governing ADR, acceptance criteria, story type, and test-evidence path. Run after /create-epics for each epic, in dependency order. Stories are what developers pick up — epics are what architects define.
Prepare a day-one patch for launch. Scopes, prioritizes, implements, and QA-gates a focused patch addressing issues found between gold master and public launch. Treats the patch as a mini-sprint with its own QA gate and rollback plan.
Section-by-section authoring of the Design Bible — the visual identity spec that gates all visual production. Defines tokens for color, type, space, radius, elevation, motion, plus app icon and splash spec. Run after /brainstorm and before /map-systems or any UX work.
Reviews any design document — concept doc, design bible, flow spec, or other architecture-adjacent design artefact — for completeness, internal consistency, and implementability. Detects PRDs and routes them to /prd-review. Use this when the doc is NOT a PRD; for PRD validation, use /prd-review directly.
Section-by-section authoring of a Product Requirements Doc for a single mobile-app system. Reads concept, systems index, dependencies, and registry; walks the user through each PRD section collaboratively; writes incrementally to file. Use when starting a new PRD or filling gaps in an existing one.
Read a story file and implement it end-to-end. Loads PRD requirement, governing ADR, control manifest, and routes to the right framework specialist (RN/Flutter/iOS/Android). Use when a story has passed /story-readiness and is ready to be built.
Estimates effort for a story, batch of stories, or epic by analyzing complexity, dependencies, historical velocity, and risk factors. Produces a structured estimate with confidence levels. Use before sprint planning or when sizing a new request.
Extracts patterns from existing source code into a structured system.md file — naming, state shape, navigation pattern, error handling, and component composition. Used as the first step inside /reverse-document and on its own when the team wants to capture undocumented conventions in a brownfield project.
★not rated 40 4mo agoA58 tokens
MIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: