/build-auto-reviewed

You will run the reviewer-gated Android development pipeline for: $ARGUMENTS

Before executing, read .claude/AGENTIC_DEV_TEAM_PIPELINE.md for the shared orchestration rules (handoff protocol, subagent mappings, approval gates, build/lint gates, reviewer-loop protocol) and read the consuming project's AGENTS.md (or CLAUDE.md) for local conventions (architecture, libraries, verification requirements). Both files are the source of truth — do not duplicate their content here.

This is the /build-auto-reviewed flow — same shape as /build-auto (no PM phase, no human gates), but each producing phase is followed by an automated reviewer that can send the work back. It assumes the feature is already understood. If the request is vague, suggest the user run /build-guided instead.

Reviewer-loop protocol (applies to every gate below):

• After the producing agent finishes, delegate to its reviewer.
• If the reviewer ends with ✅ ... APPROVED, proceed to the next phase.
• If the reviewer ends with 🔧 ... CHANGES REQUESTED, re-run the producing agent, passing it the reviewer's numbered feedback, and review again.
• A gate allows at most 2 re-runs (3 production attempts total). If the reviewer still requests changes after the 2nd re-run, STOP the whole pipeline and report to the user: the phase, the unresolved feedback, and the current artifact/diff state. Do not proceed to later phases.

Phase 1 — Architect: Delegate to the adt-android-architect subagent with the feature request. Wait for ✅ ARCHITECT DONE. Parse the artifact directory from the DONE message — it will say: "plan at pipeline_artifacts/{slug}/implementation-plan.md" Store the plan path: PLAN_PATH = pipeline_artifacts/{slug}/implementation-plan.md

Phase 1R — Architect review gate (max 2 re-runs): Delegate to the adt-android-architect-reviewer subagent. Pass PLAN_PATH.

• On ✅ PLAN APPROVED: continue to Phase 2.
• On 🔧 PLAN CHANGES REQUESTED: re-run adt-android-architect with the reviewer's feedback and the instruction to revise PLAN_PATH in place, then review again. After the 2nd failed re-run, STOP and report (see protocol).

Phase 2 — Coder (execution strategy is decided by the Architect): Read PLAN_PATH Section 3 ("Work Breakdown & Execution Strategy"). Look at the Parallel-safe field.

IF Parallel-safe is NO: Spawn ONE adt-android-coder subagent. Pass it PLAN_PATH with instructions to implement all sections sequentially in the order listed. Wait for ✅ CODER DONE.

IF Parallel-safe is YES: For each Execution Group in order (Group 1, then Group 2, etc): Spawn N adt-android-coder subagents IN PARALLEL — one per section in the group. Each coder receives: - PLAN_PATH - Explicit instruction: "Implement ONLY Section X. Do not touch files outside the file list for Section X. Other coders are working on other sections concurrently." Wait for ALL coders in the group to declare ✅ CODER DONE before starting the next group. After each group finishes, run ./gradlew lint detekt testDebugUnitTest once at the orchestrator level to catch any cross-section issues before moving to the next group.

If any coder reports a problem with its section (e.g. spec issue, unexpected file conflict), STOP the pipeline and report to the user rather than continuing.

Phase 2R — Code review gate (max 2 re-runs): After ALL coding for the feature is complete, delegate to the adt-android-code-reviewer subagent. Pass PLAN_PATH (it reviews the uncommitted diff against the plan and the project's conventions).

• On ✅ CODE APPROVED: continue to Phase 3.
• On 🔧 CODE CHANGES REQUESTED: re-run the Coder to address the feedback — spawn ONE adt-android-coder subagent with PLAN_PATH and the reviewer's numbered feedback, instructing it to fix exactly those points (regardless of the parallel-safety decision; fixes are usually small and cross-cutting). Wait for ✅ CODER DONE, then review again. After the 2nd failed re-run, STOP and report (see protocol).

Phase 3 — Tester: Delegate to the adt-android-tester subagent. Pass: PLAN_PATH Wait for ✅ TESTER DONE.

When complete, summarise the verdict from the test-results.md in the same directory as PLAN_PATH. Also report, for each review gate, how many re-runs were needed (0, 1, or 2) and whether parallel execution was used and how many adt-android-coder subagents ran, so the user can gauge token cost. If verdict is NEEDS FIXES, suggest re-running the adt-android-coder with the recommendations section as input.