grok-build

# Grok Build Orchestration The coding assistant is the orchestrator: it plans, writes self-contained task specs, dispatches them to Grok Build headlessly, reviews every diff, and owns the final result. Grok is the fast, cheap executor. Full CLI details and verified behaviors: `references/cli.md`. ## When to delegate vs keep with the orchestrator | Delegate to Grok | Keep with the orchestrator | |---|---| | Plan tasks with clear acceptance criteria | Ambiguous requirements, architecture decisions | | Boilerplate, scaffolding, CRUD | Deep cross-file debugging | | Mechanical refactors | Security-sensitive code | | Test writing from clear specs | Anything touching production infrastructure | | UI components from mockups/specs | Tasks where writing the spec ≈ doing the work | When in doubt, keep it with the orchestrator. ## Session preflight (once, before the first dispatch) 1. `grok update --check --json` — if `updateAvailable` is true, run `grok update` and confirm with `grok --version`. 2. `grok models` — if it errors or reports logged out, STOP and ask the user to run `grok login`. ## Per-task loop (sequential — the default) 1. **Spec.** Write a self-contained task file (template below) to a temp directory OUTSIDE the target repo — the harness scratchpad if one is available, else the OS temp dir. Never write it inside the target repo. Grok has zero conversation context: no one-liner prompts, ever. - POSIX: `mkdir -p "${TMPDIR:-/tmp}/grok-specs"`, then...