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)
grok update --check --json — if updateAvailable is true, run grok update and
confirm with grok --version.grok models — if it errors or reports logged out, STOP and ask the user to run
grok login.
Per-task loop (sequential — the default)
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 write task.md there.
- Windows (PowerShell):
New-Item -ItemType Directory -Force "$env:TEMP\grok-specs",
then write task.md there.
Clean state. No uncommitted source changes — commit or stash first, so the
post-run diff is exactly Grok's work. Ignore build artifacts (__pycache__, dist/,
etc.); if they show in git status, they're usually just un-gitignored, not your
concern. Never dispatch on a dirty source tree.
Dispatch.
POSIX:
grok --prompt-file <task-file> \
--output-format json \
--always-approve \
--max-turns 30 \
--cwd <repo>
Windows (PowerShell) — backtick line-continuation:
grok --prompt-file <task-file> `
--output-format json `
--always-approve `
--max-turns 30 `
--cwd <repo>
Parse the JSON output and save sessionId. (--always-approve is required for
headless runs — --permission-mode acceptEdits silently cancels edits with no
interactive approver. See references/cli.md.) For a high-stakes task, add --check
so Grok self-verifies before you review; skip it otherwise (it ~doubles latency).
Review gate — non-negotiable.
- Read the diff yourself (
git diff -- <files from the spec> to skip artifact noise):
does it do the task, only the task, and match repo conventions?
- Run the acceptance commands from the spec.
- Pass → commit with a clear message following the repo's convention → next task.
- Fail → fix-up:
grok --resume <sessionId> -p "<specific feedback>" --always-approve --output-format json. Max 2 fix-up rounds. Still failing →
revert Grok's changes (git checkout -- .; git clean -fd for new files), do the
task yourself, and tell the user Grok couldn't complete it.
Task spec template
# Task: <one-line title>
## Context
- Repo: <path> — <one line on what the project is>
- Conventions: <test runner, formatter, a good example file to imitate>
## Files
- Modify: <path>
- Create: <path>
## Task
<precise description of the change>
## Constraints
- Do not modify any files other than those listed above.
- <other constraints>
## Acceptance criteria
- `<exact command>` <expected result>
Executing a Markdown implementation plan
- One plan task per dispatch, in order.
- Check off the plan's task checkboxes (
- [ ] → - [x]) as each task lands and passes
the review gate.
- If the plan explicitly marks tasks as independent, see Parallel dispatch below;
otherwise stay sequential.
Parallel dispatch (opt-in exception, not the default)
Only when a plan explicitly marks tasks independent: dispatch each with
--worktree=<task-slug>, run concurrently, then review and merge one worktree at a
time through the same review gate. Merge conflicts usually eat the savings — prefer
sequential.
Failure handling
| Failure |
Action |
stopReason: "Cancelled", empty text, no diff |
Missing --always-approve — retry with it |
| CLI error / timeout |
Retry once; then do the task yourself and note the fallback |
| Auth expired |
Stop; ask the user to run grok login |
| 2 fix-up rounds exhausted |
Revert Grok's diff; the orchestrator finishes the task |
| Dirty tree at dispatch |
Refuse; commit/stash first |
Models
Default grok-4.5. Add -m grok-composer-2.5-fast only for trivial mechanical tasks.
1---2name: grok-build3description: Orchestrate coding work by delegating well-specified implementation tasks to xAI's Grok Build CLI (grok) running headlessly, while the coding assistant plans, writes the task specs, reviews every diff, and owns the result. Use when user says: 'use grok', 'grok build', 'delegate to grok', 'have grok implement', 'have grok execute', 'have grok build', 'send to grok', 'execute this plan with grok'. Executes a Markdown implementation plan task-by-task, or ad-hoc tasks with an inline spec.4license: Apache-2.05---6
7# Grok Build Orchestration
8
9The coding assistant is the orchestrator: it plans, writes self-contained task specs,
10dispatches them to Grok Build headlessly, reviews every diff, and owns the final result.
11Grok is the fast, cheap executor. Full CLI details and verified behaviors: `references/cli.md`.
12
13## When to delegate vs keep with the orchestrator
14
15| Delegate to Grok | Keep with the orchestrator |
16|---|---|
17| Plan tasks with clear acceptance criteria | Ambiguous requirements, architecture decisions |
18| Boilerplate, scaffolding, CRUD | Deep cross-file debugging |
19| Mechanical refactors | Security-sensitive code |
20| Test writing from clear specs | Anything touching production infrastructure |
21| UI components from mockups/specs | Tasks where writing the spec ≈ doing the work |
22
23When in doubt, keep it with the orchestrator.
24
25## Session preflight (once, before the first dispatch)
26
271. `grok update --check --json` — if `updateAvailable` is true, run `grok update` and
28 confirm with `grok --version`.
292. `grok models` — if it errors or reports logged out, STOP and ask the user to run
30 `grok login`.
31
32## Per-task loop (sequential — the default)
33
341. **Spec.** Write a self-contained task file (template below) to a temp directory
35 OUTSIDE the target repo — the harness scratchpad if one is available, else the OS
36 temp dir. Never write it inside the target repo. Grok has zero conversation context:
37 no one-liner prompts, ever.
38 - POSIX: `mkdir -p "${TMPDIR:-/tmp}/grok-specs"`, then write `task.md` there.
39 - Windows (PowerShell): `New-Item -ItemType Directory -Force "$env:TEMP\grok-specs"`,
40 then write `task.md` there.
412. **Clean state.** No uncommitted *source* changes — commit or stash first, so the
42 post-run diff is exactly Grok's work. Ignore build artifacts (`__pycache__`, `dist/`,
43 etc.); if they show in `git status`, they're usually just un-gitignored, not your
44 concern. Never dispatch on a dirty source tree.
453. **Dispatch.**
46
47 POSIX:
48
49 ```bash
50 grok --prompt-file <task-file> \
51 --output-format json \
52 --always-approve \
53 --max-turns 30 \
54 --cwd <repo>
55 ```
56
57 Windows (PowerShell) — backtick line-continuation:
58
59 ```powershell
60 grok --prompt-file <task-file> `
61 --output-format json `
62 --always-approve `
63 --max-turns 30 `
64 --cwd <repo>
65 ```
66
67 Parse the JSON output and save `sessionId`. (`--always-approve` is required for
68 headless runs — `--permission-mode acceptEdits` silently cancels edits with no
69 interactive approver. See `references/cli.md`.) For a high-stakes task, add `--check`
70 so Grok self-verifies before you review; skip it otherwise (it ~doubles latency).
714. **Review gate — non-negotiable.**
72 - Read the diff yourself (`git diff -- <files from the spec>` to skip artifact noise):
73 does it do the task, only the task, and match repo conventions?
74 - Run the acceptance commands from the spec.
75 - **Pass** → commit with a clear message following the repo's convention → next task.
76 - **Fail** → fix-up: `grok --resume <sessionId> -p "<specific feedback>"
77 --always-approve --output-format json`. **Max 2 fix-up rounds.** Still failing →
78 revert Grok's changes (`git checkout -- .`; `git clean -fd` for new files), do the
79 task yourself, and tell the user Grok couldn't complete it.
80
81## Task spec template
82
83```markdown
84# Task: <one-line title>
85
86## Context
87- Repo: <path> — <one line on what the project is>
88- Conventions: <test runner, formatter, a good example file to imitate>
89
90## Files
91- Modify: <path>
92- Create: <path>
93
94## Task
95<precise description of the change>
96
97## Constraints
98- Do not modify any files other than those listed above.
99- <other constraints>
100
101## Acceptance criteria
102- `<exact command>` <expected result>
103```
104
105## Executing a Markdown implementation plan
106
107- One plan task per dispatch, in order.
108- Check off the plan's task checkboxes (`- [ ]` → `- [x]`) as each task lands and passes
109 the review gate.
110- If the plan explicitly marks tasks as independent, see Parallel dispatch below;
111 otherwise stay sequential.
112
113## Parallel dispatch (opt-in exception, not the default)
114
115Only when a plan explicitly marks tasks independent: dispatch each with
116`--worktree=<task-slug>`, run concurrently, then review and merge one worktree at a
117time through the same review gate. Merge conflicts usually eat the savings — prefer
118sequential.
119
120## Failure handling
121
122| Failure | Action |
123|---|---|
124| `stopReason: "Cancelled"`, empty text, no diff | Missing `--always-approve` — retry with it |
125| CLI error / timeout | Retry once; then do the task yourself and note the fallback |
126| Auth expired | Stop; ask the user to run `grok login` |
127| 2 fix-up rounds exhausted | Revert Grok's diff; the orchestrator finishes the task |
128| Dirty tree at dispatch | Refuse; commit/stash first |
129
130## Models
131
132Default `grok-4.5`. Add `-m grok-composer-2.5-fast` only for trivial mechanical tasks.
gabrielmoreira