---

name: arib-build argument-hint: "<goal>" description: "Engine | Command the engineering team to deliver a known goal — dispatches the engineer-manager to decompose → dispatch specialists (parallel where safe) → integrate → reconcile (verification-agent) → merge gate. Scales its own reach: runs inline for a bounded goal, escalates to a parallel Workflow for a broad one, and paces under /loop for a multi-turn campaign — only when it needs to. Use when a goal needs a coordinated TEAM, not one specialist. Sibling of /arib-engine: the engine DISCOVERS its own backlog; /arib-build EXECUTES a goal you hand it."

/arib-build — command the engineering team

Hand the project engineering manager a goal and it runs the team: decomposes the work, dispatches the right specialists (in parallel where safe), integrates their output, reconciles it against your goal, and stops at the merge gate. One trigger; the manager conducts the rest.

This skill is thin on purpose — the orchestration logic lives in the engineer-manager agent (.claude/agents/engineer-manager.md). This is the invocation.

When to use it (and when not)

• Use /arib-build when a goal needs several specialists coordinated — e.g. "add the refund endpoint" (architect → db migration review → implement → security + test fan-out → reconcile). The manager picks and sequences the team.
• Use /arib-engine for a sustained, self-directed campaign where the backlog is discovered, not given ("harden the whole codebase until done"). Engine finds the work; /arib-build executes the work you name. Same merge gate, same guardrails.
• Just call one specialist / do the fix for a single bounded task — a whole team is overkill (the manager itself will say so and shrink the dispatch).

Step 0 — Parse the mandate

/arib-build <goal>

State in one line what you understood (the goal + whether a waves/<id>/PLAN.md or /arib-wave-plan lock already exists to use as the decompose input).

Step 0.5 — Choose the execution mode (escalate only if it needs)

/arib-build sizes the goal and runs the smallest mechanism that fits. This decision lives at the skill level because the skill runs in the main session — which holds the Workflow tool and can arm /loop/ScheduleWakeup; the engineer-manager agent dispatches via Task (capped at one level), so broad/multi-turn reach is the skill's job.

| Scope signal | Mode | What runs | |---|---|---| | One coherent change, a few specialists, fits one turn | Inline (default) | Task(engineer-manager, goal=…) — the manager fans out via Task | | Broad / parallel / verify-heavy — many independent units, a multi-stage pipeline, or N findings each needing adversarial verification | Workflow | The skill launches a Workflow: the manager's decompose output becomes the task list; pipeline()/parallel() run the units with bounded concurrency + schema'd verdicts | | Campaign — won't finish in one turn, or each step is gated on an external event (CI, deploy, a long build) | /loop | Run under /loop (the canonical scheduler); each tick does one unit (inline or a Workflow). Under unattended mode (ADR-030) it proceeds without pausing |

"Runs if it needs" — the discipline: escalate up only when the scope warrants, never down-justify ceremony. Don't spin a Workflow for a one-file fix; don't /loop a single-turn goal. The mode can compose — a /loop tick may launch a Workflow, and a Workflow stage may dispatch specialists. State the chosen mode in the one-line confirmation.

Inline dispatch (the default path):

Task(engineer-manager, goal="<goal>", plan=<PLAN.md if present>)

Step 1 — Let the manager run its cycle

The engineer-manager agent owns the loop (see its definition):

decompose  → Task(architect) + Task(planner) in parallel → task graph
dispatch   → fan-out specialist batches (no write-conflicts, no read-after-write)
integrate  → parent session converges all writes
verify     → Task(verification-agent) LAST → RECONCILED | GAP (re-loop) | HOLD (human)

Report a running log: which specialist did what, each verdict, what merged.

Step 2 — The merge gate (same in ALL three modes, never weakened)

The mode (inline / Workflow / /loop) changes only how the work is dispatched and paced — it changes nothing about authority. In every mode, merge to main follows CONSTRAINTS #17: blocking CI green and verification-agent RECONCILED and not a high-stakes class. Money/tax, auth, tenant-isolation, compliance, secrets, breaking-migration always hold for a human. Workflow agents and /loop ticks hit the same fail-closed hooks and the same autonomy-guard caps (CCM_AUTONOMY=1) as an inline run. Scaling reach never scales authority.

Examples

# Inline — bounded goal, one turn
/arib-build add a soft-delete flag to the Patient entity
Manager: decompose → architect + planner ▶ graph(4) ▶ database-guardian ▶ implement
  ▶ fan-out code-reviewer+security-auditor+test-engineer ▶ verification-agent → GAP
  → re-loop node 3 → RECONCILED ▶ high-stakes (migration) → HOLD for human merge.

# Workflow — broad goal, the skill escalates to parallel orchestration
/arib-build migrate all 40 controllers to the new auth guard
→ decompose → 40 independent units → LAUNCH Workflow: pipeline(units, migrate, verify)
  with bounded concurrency; each unit verified by verification-agent; non-high-stakes
  auto-merge, the guard change itself held for a human.

# Loop — campaign, the skill paces across turns
/loop /arib-build harden every money-math path in the billing module
→ each tick takes one path: build → reconcile → (auto-merge non-high-stakes / hold money
  paths) → re-arm; stops when the backlog is dry. Unattended mode = no pauses (ADR-030).

Anti-patterns

Doing the work in the skill instead of dispatching the manager · inventing merge authority (the gate is CONSTRAINTS #17) · using /arib-build for a one-line fix · spinning a Workflow or a /loop when an inline run fits (escalate only if it needs) · letting a Workflow/loop path quietly skip the merge gate · treating it as a rival to /arib-engine rather than its known-plan sibling.