app-dev-team

🏗️ AI App Studio

Describe your app idea in one line. Get a shipped iOS & Android app.

AI App Studio is a team of 30 AI specialists — a CEO, product manager, designers, iOS/Android engineers, a code reviewer, QA, and a release manager — that works like a real software studio. It takes your idea from scope → design → code → review → store, building in parallel, reviewing and fixing its own work, and stopping for you at only the two moments that matter: what we're building and whether to ship.

Ships as the app-dev-team Claude Code plugin — see Install.

---

30-second version

# In Claude Code, from an empty folder:
/app-run "A habit tracker for new parents, iOS + Android, freemium"

That one command spins up the whole studio. It pauses once so you can approve the plan, then builds the app autonomously — parallel engineers, automated code review, QA, and a bug-fix loop — giving you a short standup after each round, and pauses again only when it's ready to ship.

Already have an app? Point it at your existing code instead and it works in reverse — reads the codebase, grades it against professional standards, and closes the gaps:

/app-onboard      # understand the existing app
/app-audit        # score it, list the issues, fix them

---

What it actually does

Most "AI builds your app" tools are a single agent improvising — it writes some code, forgets the plan, and leaves you to be the project manager. Real apps aren't built that way. They're built by a team with roles, handoffs, conventions, and a review gate.

AI App Studio models that team. Each role is a focused AI specialist that does one job well and hands off to the next:

flowchart TD
    idea([💡 Your one-line idea])

    subgraph EXEC["🎩 Executive — decides what and why"]
        direction LR
        CEO[CEO<br/>vision and goals]
        CPO[CPO<br/>product spec]
        CTO[CTO<br/>tech and architecture]
    end

    subgraph MGMT["🗂️ Management — plans and coordinates"]
        direction LR
        TL[Tech Lead<br/>build specs]
        TM[Tech Manager<br/>runs the board · merge gate]
    end

    subgraph ENG["⚙️ Engineering — builds and verifies"]
        direction LR
        IOS[iOS dev]
        AND[Android dev]
        BE[Backend dev]
        MON[Monetization]
        REV[Code Reviewer]
        QA[QA]
        VER[Verification]
    end

    subgraph GROW["🎨 Design and Growth"]
        direction LR
        UX[UX Designer]
        ASO[Store Listing]
        DATA[Analytics]
    end

    subgraph REL["🚀 Platform and Release"]
        direction LR
        OPS[DevOps]
        SEC[Security]
        RM[Release Manager]
    end

    idea --> EXEC --> MGMT --> ENG --> GROW --> REL --> ship([📦 Shipped app on the store])

The engineers work in parallel. The code reviewer is a real gate — nothing merges until it passes (and on iOS it runs ~25 specialist auditors for accessibility, concurrency, security, and more). QA files bugs, the team fixes them in a loop, and you get a daily standup the whole way.

---

How it runs — the autonomy model

You stay in control at exactly two gates. Everything between them runs on its own.

flowchart LR
    A([💡 idea]) --> B["/app-init<br/>vision · spec · architecture"]
    B --> G1{{"🔒 GATE 1<br/>scope-lock<br/><i>you approve the plan</i>"}}
    G1 --> C["/app-plan<br/>parallel board"]
    C --> D["/app-build loop<br/>parallel devs → code review →<br/>merge → QA → bug fixes → standup"]
    D --> E["ship-readiness<br/>store assets · security · analytics"]
    E --> G2{{"🚀 GATE 2<br/>ship<br/><i>you confirm</i>"}}
    G2 --> F([📦 store upload])

    style G1 fill:#fde68a,stroke:#b45309,color:#000
    style G2 fill:#bbf7d0,stroke:#15803d,color:#000

"Mostly autonomous" means it shows you the seams. It never invents intent when a requirement is ambiguous — it writes the blocker into the standup and surfaces it to you verbatim, instead of guessing and building the wrong thing.

Board integrity — the loop can't quietly drop work

The board is the team's only memory across agent invocations, and every row is written by an agent editing a Markdown table. So two checks run mechanically rather than on trust:

• Board doctor (scripts/board-doctor.mjs) runs before any agent is spawned, every round. It catches the failure the loop is structurally blind to: a ticket whose dependency is blocked is never "ready" and never in review, so the sprint would otherwise exit and report success without ever mentioning it. It also catches missing/invalid owners, broken and circular dependencies, self-review, tickets that reached qa/done without an approval on record, and a breached review-cycle cap. Anomalies stop the loop; nothing spawns until the board is repaired.
• DONE verification (scripts/verify-done.sh) checks a developer's DONE: APP-NNN against git before the row moves to review — branch exists, commits are actually there, files changed, and the test command exits zero. A self-reported "tests: all green" is never taken at face value.
• Review verdict enforcement (hooks/require-review-verdict.sh) is a Claude Code SubagentStop hook: a code-reviewer subagent cannot stop until the board's own event log shows a real approved/changes verdict it recorded, or a documented BLOCKED refusal. Found live, on this plugin's own PR review: a reviewer went idle three times, producing nothing, and two nudges didn't change that. The first version of this hook checked the agent's own transcript for the right words — an independent review reproduced that a transcript merely quoting the required command satisfied it with zero work done. It now checks the append-only log directly; a false claim can't forge a real log line the way it can forge a sentence.
• Base-vs-head regression check (scripts/wave-integrate.mjs --check-baseline) — on a failed wave, checks whether the unmodified integration branch also fails the same suite before blaming the tickets in it. Opt-in and additive: it changes nothing about a green wave, and never turns a real failure into a pass — it only tells you whether the failure pre-dates the wave.

Every gate above is plain Node + POSIX sh with no dependencies, and the board-doctor skill carries a manual checklist so a vanilla install without Node still performs the check by hand.

How the agents coordinate

Agents don't shout into one shared room, and they don't route every sentence through a human.

• Isolation. Every writing agent gets its own git worktree, created before it is spawned. Without this, parallel agents corrupt each other — measured, not theorised: a dry run of two deliberately independent tickets in one tree produced a commit containing the other ticket's half-written files, one agent burning ~50% of its budget discovering and redoing work it had already done correctly, and two branches with add/add conflicts on all 8 files. (full write-up)
• A real channel. docs/team/messages.jsonl is an append-only event log — question, answer, handoff, blocker, escalation, decision — so an IC can ask the tech lead one question and keep working, instead of hard-blocking and paying for a full re-spawn. docs/team/messages.md is its generated view; channels and threads are queries over the log, never places state is written.
• Messages that have to produce something. Every material message must yield a decision, a state transition, an artifact update or a timed follow-up, or it is refused at send time. An answer that names no artifact is refused too: a closed ledger is not delivery.
• An anti-ping-pong guard. Two agents can burn a whole budget agreeing with each other, so the send helper enforces limits: 10 messages per role per round, 2 per pair per ticket, 4 roles per chain, 12 per ticket, no duplicate question, no reopening a decided thread without new evidence. Breach one and you must escalate to the tech manager instead of re-sending.
• Parallelism judged on files, not features. Two tickets that touch the same file are serialized however unrelated they look on the board.

Seeing the state

node scripts/board-render.mjs docs/31-board.md --out docs/32-board-view.md

A terminal kanban, per-owner load, a NEEDS ATTENTION block, and a Mermaid dependency graph that renders on GitHub — with stranded and blocked tickets outlined in red. /app-status prints it; /app-build regenerates it each round.

Reviews that find real defects

The reviewer no longer just reads a diff. It applies the defect-hunting skill, mined from a real remediation programme where twelve screen-by-screen review rounds found nothing new and one round organised by data path found dozens of live defects:

• The second write path. In every miss, the reviewed surface was correct and the bug was elsewhere — add validated but edit didn't; the reader was fixed and the writer destroyed data; the picker's success branch was right and its cancel branch wiped the photo. The reviewer must enumerate every writer and reader of the data a diff touches.
• Execute constants, never certify by reading. A plausibility envelope that read perfectly and survived 35 sprints rejected the median subject at 26 of 61 ages. Mis-calibration is invisible to inspection because the code is correct.
• A rule that cannot fail is worse than no rule. Ten of nineteen real guard rules were bypassable, all from contains() over prose — one was tripped by its own comment. New rules must be watched failing before they are trusted.

verification-engineer owns this at release time and gates /app-ship.

Two more additions to the review itself: it now exercises a ticket's acceptance criteria black-box, before opening the diff — running the actual behavior rather than reading the code first, so the reviewer isn't reasoning from the same source that may have produced the bug. And how much ceremony a review carries scales with the ticket's own size (process-tiering, XS through XL) — a one-line fix doesn't walk the same process as a multi-screen feature, except nothing ever lightens for a ticket touching auth, payments, PII, or anything security-reviewer owns, regardless of size.

The team checks itself

node scripts/team-doctor.mjs

board-doctor validates a project's board. team-doctor validates the team definition — the gaps that are invisible by construction: a role nothing ever spawns, a role that can own a ticket but that /app-build never launches (the ticket is never picked up and never reported), a referenced skill that doesn't exist, a handoff pointing at nobody, a doc one role writes that no role reads. Each of those was a live defect found by hand once.

Two ways in: new app or existing app