/app-run

description: Mostly-autonomous end-to-end run — idea → scope-lock → sprint loop → ship-readiness, surfacing only blockers and the two human gates (scope-lock, ship)
argument-hint: [one-line idea, optional] [--yolo to skip scope-lock] [--utility for a utility-tier app]
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, Agent

/app-run — Drive the whole build, mostly on its own

Idea / flags: $ARGUMENTS

This is the autonomous driver. It chains init → plan → build → standup → loop until the sprint is done or a true blocker hits. **Only two things stop for the user: scope-lock and ship.** Everything else streams as standup reports. Wrap this command in `/loop` for fully self-paced execution.

Operating rules

• The team **never invents intent.** When a requirement is genuinely ambiguous, write the blocker

to the standup and surface it verbatim — do not guess.

• All build agents invoke the `house-conventions` skill before working (House KB = `knowledge/`).
• Honor the existing safety rails: 2-cycle review cap, no auto-merge across `REQUEST CHANGES`,

one agent per ticket at a time, no destructive data actions.

• **The board doctor gate is not skippable, including under `--yolo`.** `--yolo` skips *human*

gates, never correctness gates. An autonomous run is exactly the situation where a silently stranded ticket goes unnoticed for the whole sprint.

• **No `DONE` is believed unverified.** `verify-done.sh` runs on every developer return — `--static`

by default, which checks the branch, the commits and the changed files and states plainly that the suite has not run. The suite runs once per wave on the merged tree (step 4). "Verified" here never means "an agent said so".

Steps

1. **Detect greenfield vs brownfield.** Using the `brownfield-onboarding` skill's detection, check whether the target directory already contains an app.

Either branch writes `docs/02-team-roster.md` via the `role-activation` skill before it spawns anyone. **`--utility` sets the tier**; without it the tier is derived and stated at Gate 1, where scope is approved anyway. Everything after this step spawns from the roster and never from a list in this file — read it, do not re-derive it. `off` roles are not spawned; their gates report `N/A` with the roster's reason, never silence.

• **Empty / no app → greenfield:** run `/app-init` with the idea (requirements-intake → CEO

vision → parallel CPO/CTO → parallel ux-architect/product-designer/tech-lead/devops-engineer → project bootstrap incl. `CLAUDE.md` + git). `/app-init` ends with its own scope-lock gate — **this command owns that gate (step 2), so `/app-init` skips it here** and the user is asked once, not twice.

• **Existing app → brownfield:** run `/app-onboard` (reverse-engineer the as-built baseline +

`CLAUDE.md`), then `/app-audit` (grade vs the House KB → `docs/80-audit.md` → remediation backlog). If an idea/goal was given, treat it as the upgrade goal and add it as feature tickets alongside the `AUDIT-NNN` remediation tickets.

1a. **Intent validation — before Gate 1, outside the chain that wrote the docs.** Spawn `product-validator` (active per the roster). It compares `docs/00-founder-intent/` — the founder's recorded words — against `docs/10-prd.md` and the vision, writes `docs/16-intent-validation.md`, and returns `INTENT: ALIGNED | DRIFTED | CANNOT EVALUATE`. Then:

   node "${CLAUDE_PLUGIN_ROOT}/scripts/founder-intent.mjs" --project-root .
   node "${CLAUDE_PLUGIN_ROOT}/scripts/trace.mjs" --project-root .

The first proves the founder record has not been edited to match the plan; the second walks the goal → outcome → requirement → criterion → ticket → test → analytics chain and reports every break, every conflict it resolved by precedence, and every conditional founder gate that fired. **All of it goes into the Gate 1 brief and none of it is resolved by an agent.** `--yolo` skips human gates, not this: it is the only check in the system that is not inside the loop it is checking. `trace.mjs` exit 2 is `CANNOT EVALUATE`, never a pass.

2. **GATE 1 — scope-lock / audit-approval (human).**

• *Greenfield:* print a one-screen brief — vision, P0 feature list, architecture headline,

rough effort, top risk, **plus the roster headline: tier (and whether it was flagged or derived), product type, and every `off` role with its reason** — and ask *"Approve scope and proceed to build?"* Activation is a scope decision, so it is reviewed at the gate that already reviews scope. **This adds no third gate**; a user who disagrees with the derived tier says so here, and `docs/02-team-roster.md` is rewritten before anything spawns.

• *Brownfield:* print the audit scorecard and the remediation backlog grouped by severity and

Safe/Risky, and ask *"Which gaps should we fix?"* Risky changes proceed only if approved here. Wait for the answer. With `--yolo`, skip the gate (greenfield: auto-approve scope; brownfield: fix all S1/S2 + Safe, defer Risky) and log the decision.

3. **Plan.** Run `/app-plan` (tech-manager builds the parallel board via `sprint-planner`), which runs **non-interactively here** — scope was approved at Gate 1 and this command has no third gate. Ensure every P0 feature has a paired `APP-NNN-analytics` ticket (data-analyst schema feeds this).

Brownfield reaches this step with a real backlog: `/app-onboard` writes `docs/11-backlog.md` (existing features as baseline rows) and `docs/00-vision.md`, and `/app-audit` has already put `AUDIT-NNN` remediation tickets on the board. `/app-plan` sequences those plus the upgrade goal; it does not re-propose the app that already exists.

4. **Build loop.** Run the `/app-build` loop autonomously, round after round:

• round preconditions (`orchestrator round`: board · budget · merge truth · toolchain · CI ·

worktree pool) → parallel IC