build

name	build
description	Default engineering workflow. Classify a technical request, route it through the native T1/T2/T3 engineering fleet, and return only independently verified completion to the orchestrator.
when_to_use	Use proactively whenever the incoming user request is an engineering request; users can also force it with /build.
argument-hint	<engineering request>

Build workflow

This is the default workflow for engineering requests. It runs in the interactive orchestrator session, preserves human approval, and uses the engineering-fleet skill rather than a project-authored JavaScript workflow runtime.

1. Classify the current request as engineering using docs/BUILD-CONTRACT.md and docs/PLAN-CONTRACT.md. If it is not engineering, say so and return to the orchestrator; do not dispatch t1-engineer.
2. If the request is non-basic, dispatch one foreground custom planner with PLAN_JOB. Planner performs local analysis, invokes nested Researcher only when it creates a precise PLANNING_RESEARCH_REQUEST, runs the minimum DESIGN_ROUTE and independent review for user-visible work, then invokes nested Scribe with PLANNING_HANDOFF. Wait for Planner's PLAN_READY or PLAN_BLOCKED; do not pre-spawn specialists, poll with Agent, or interpret idle as completion. If user input/design selection is needed, resume the original Planner through SendMessage. Run eligible PLAN_DUCK from docs/JUDGE-CONTRACT.md, then obtain explicit user approval of the Scribe plan path and pass that path to T1. Do not use research or judging to add product scope or override explicit user requirements.
3. For a basic request only, create an ENGINEERING_JOB envelope directly. For every planned job, include approved_plan, preserve the plan's outcome, scope, non-goals, references, constraints, and acceptance checks, and include research_context only when completed advisory evidence is material to implementation.
4. If a missing answer materially changes implementation, ask one concise question. Otherwise state a safe bounded assumption in the envelope.
5. Load engineering-fleet and cross-vendor-judging. For a non-basic or high-risk job, obtain a compact ENGINEERING_ROUTE from Engineering Lead. Delegate the initial bounded job to T1. A JOB_DONE starts, but does not complete, the post-writer gates: eligible Codex CODE_REVIEW, verifier, risk-triggered VERIFICATION_CHALLENGE, browser-validator for browser_ui_validation: required, and eligible Studio/high-value VISUAL_REVIEW. Deterministic failures dominate judge output. A judge-driven loop is capped at one; a counted deterministic remediation is only a completed writer cycle that receives VERIFICATION_NEEDS_FIX or BROWSER_NEEDS_FIX.
6. After two counted T1 failures, send an ENGINEERING_ESCALATION_PACKET to T2 and make it the sole writer. T2 has two counted cycles, then blocks for user review/replanning. A research, stale-plan, credentials, unsafe-command, or unavailable-prerequisite result is a normal blocker and never a counted escalation attempt. If BROWSER_BLOCKED reports playwright_missing, obtain explicit user approval before re-dispatching Browser Validator with the pinned Playwright setup authority. If BROWSER_BLOCKED reports tauri_driver_missing, obtain explicit user approval before re-dispatching Browser Validator with the pinned tauri-driver setup authority (tauri_driver_setup_authorized: yes).
7. For an explicitly approved extreme route, the Orchestrator creates an in-process team of Engineering Lead, T1, and T3. T3 is read-only and can recommend T2 promotion; T2 may start only after T1 returns WRITER_RELEASED. If teams are unavailable, use serial Lead/T3 checkpoints. Do not start a persistent team, project JavaScript workflow runtime, worktree, or SDK program by default.
8. On JOB_DONE, check changed paths, TDD evidence, verification, quality review, stale-plan status, inherited judge-finding disposition, browser-validation inputs, and DOCUMENTATION_HANDOFF when documentation is needed. Require resolved applicable judge policy actions, VERIFICATION_PASS, and applicable BROWSER_PASS/BROWSER_NOT_APPLICABLE before reporting completion. Respect the standard two-call and high-risk/Studio four-call caps. On JOB_BLOCKED with Research needed, route through Researcher; on Plan stale, create a new plan or obtain explicit reapproval.

For /build $ARGUMENTS, treat $ARGUMENTS as the request. When auto-invoked, use the current user request.