Grok Build Orchestration
When to Use
- Use when delegating a well-specified implementation task to xAI's Grok Build CLI running headlessly
- Use when executing a Markdown implementation plan task-by-task with a diff review after each task
- Use when the user says "use grok", "grok build", "have grok implement", or "send to grok"
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.
Safety Gate
Before every dispatch, show the user the exact task specification that will be sent to xAI,
the target worktree, and the permission mode. Obtain explicit approval to disclose that text
and to let Grok edit the scoped worktree. Never include secrets, proprietary source, customer
data, or credentials in a task specification. Do not run grok update, --always-approve,
or a destructive recovery command without separate, explicit approval.
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, tell the user. Run
grok update only after explicit approval, then 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. Use it only after the user explicitly approves Grok editing this
exact scoped worktree. 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 → ask the user before a fix-up or any reset. Never run
git checkout -- . or
git clean -fd automatically; preserve the diff for review and use a non-destructive
recovery plan unless the user explicitly authorizes otherwise.
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 |
Preserve the diff, ask the user for a recovery decision, then finish the task manually if authorized |
| Dirty tree at dispatch |
Refuse; commit/stash first |
Limitations
- Grok receives the approved task specification; it is a third-party service and should not
receive secrets, proprietary material, personal data, or customer data.
--always-approve allows edits without an interactive approval prompt. It must be limited to
a clean, explicitly approved worktree and never substitutes for the orchestrator's review.- Model output can be incorrect, insecure, incomplete, or out of scope. Review the diff and
run the acceptance checks before accepting any change.
- This skill does not authorize installations, updates, commits, pushes, deployments, or
destructive cleanup.
Models
Default grok-4.5. Add -m grok-composer-2.5-fast only for trivial mechanical tasks.
Source: sickn33/agentic-awesome-skills → skills/grok-build/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/grok-build/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/grok-build/SKILL.md
1---2name: grok-build3description: Delegate well-specified implementation tasks to xAI's Grok Build CLI running headlessly while the orchestrating agent plans, writes task specs, reviews every diff, and owns the result.4---5
6
7# Grok Build Orchestration
8
9## When to Use
10
11- Use when delegating a well-specified implementation task to xAI's Grok Build CLI running headlessly
12- Use when executing a Markdown implementation plan task-by-task with a diff review after each task
13- Use when the user says "use grok", "grok build", "have grok implement", or "send to grok"
14
15The coding assistant is the orchestrator: it plans, writes self-contained task specs,
16dispatches them to Grok Build headlessly, reviews every diff, and owns the final result.
17Grok is the fast, cheap executor. Full CLI details and verified behaviors: `references/cli.md`.
18
19## Safety Gate
20
21Before every dispatch, show the user the exact task specification that will be sent to xAI,
22the target worktree, and the permission mode. Obtain explicit approval to disclose that text
23and to let Grok edit the scoped worktree. Never include secrets, proprietary source, customer
24data, or credentials in a task specification. Do not run `grok update`, `--always-approve`,
25or a destructive recovery command without separate, explicit approval.
26
27## When to delegate vs keep with the orchestrator
28
29| Delegate to Grok | Keep with the orchestrator |
30|---|---|
31| Plan tasks with clear acceptance criteria | Ambiguous requirements, architecture decisions |
32| Boilerplate, scaffolding, CRUD | Deep cross-file debugging |
33| Mechanical refactors | Security-sensitive code |
34| Test writing from clear specs | Anything touching production infrastructure |
35| UI components from mockups/specs | Tasks where writing the spec ≈ doing the work |
36
37When in doubt, keep it with the orchestrator.
38
39## Session preflight (once, before the first dispatch)
40
411. `grok update --check --json` — if `updateAvailable` is true, tell the user. Run
42 `grok update` only after explicit approval, then confirm with `grok --version`.
432. `grok models` — if it errors or reports logged out, STOP and ask the user to run
44 `grok login`.
45
46## Per-task loop (sequential — the default)
47
481. **Spec.** Write a self-contained task file (template below) to a temp directory
49 OUTSIDE the target repo — the harness scratchpad if one is available, else the OS
50 temp dir. Never write it inside the target repo. Grok has zero conversation context:
51 no one-liner prompts, ever.
52 - POSIX: `mkdir -p "${TMPDIR:-/tmp}/grok-specs"`, then write `task.md` there.
53 - Windows (PowerShell): `New-Item -ItemType Directory -Force "$env:TEMP\grok-specs"`,
54 then write `task.md` there.
552. **Clean state.** No uncommitted *source* changes — commit or stash first, so the
56 post-run diff is exactly Grok's work. Ignore build artifacts (`__pycache__`, `dist/`,
57 etc.); if they show in `git status`, they're usually just un-gitignored, not your
58 concern. Never dispatch on a dirty source tree.
593. **Dispatch.**
60
61 POSIX:
62
63 ```bash
64 grok --prompt-file <task-file> \
65 --output-format json \
66 --always-approve \
67 --max-turns 30 \
68 --cwd <repo>
69 ```
70
71 Windows (PowerShell) — backtick line-continuation:
72
73 ```powershell
74 grok --prompt-file <task-file> `
75 --output-format json `
76 --always-approve `
77 --max-turns 30 `
78 --cwd <repo>
79 ```
80
81 Parse the JSON output and save `sessionId`. (`--always-approve` is required for
82 headless runs — `--permission-mode acceptEdits` silently cancels edits with no
83 interactive approver. Use it only after the user explicitly approves Grok editing this
84 exact scoped worktree. See `references/cli.md`.) For a high-stakes task, add `--check`
85 so Grok self-verifies before you review; skip it otherwise (it ~doubles latency).
864. **Review gate — non-negotiable.**
87 - Read the diff yourself (`git diff -- <files from the spec>` to skip artifact noise):
88 does it do the task, only the task, and match repo conventions?
89 - Run the acceptance commands from the spec.
90 - **Pass** → commit with a clear message following the repo's convention → next task.
91 - **Fail** → ask the user before a fix-up or any reset. Never run `git checkout -- .` or
92 `git clean -fd` automatically; preserve the diff for review and use a non-destructive
93 recovery plan unless the user explicitly authorizes otherwise.
94
95## Task spec template
96
97```markdown
98# Task: <one-line title>
99
100## Context
101- Repo: <path> — <one line on what the project is>
102- Conventions: <test runner, formatter, a good example file to imitate>
103
104## Files
105- Modify: <path>
106- Create: <path>
107
108## Task
109<precise description of the change>
110
111## Constraints
112- Do not modify any files other than those listed above.
113- <other constraints>
114
115## Acceptance criteria
116- `<exact command>` <expected result>
117```
118
119## Executing a Markdown implementation plan
120
121- One plan task per dispatch, in order.
122- Check off the plan's task checkboxes (`- [ ]` → `- [x]`) as each task lands and passes
123 the review gate.
124- If the plan explicitly marks tasks as independent, see Parallel dispatch below;
125 otherwise stay sequential.
126
127## Parallel dispatch (opt-in exception, not the default)
128
129Only when a plan explicitly marks tasks independent: dispatch each with
130`--worktree=<task-slug>`, run concurrently, then review and merge one worktree at a
131time through the same review gate. Merge conflicts usually eat the savings — prefer
132sequential.
133
134## Failure handling
135
136| Failure | Action |
137|---|---|
138| `stopReason: "Cancelled"`, empty text, no diff | Missing `--always-approve` — retry with it |
139| CLI error / timeout | Retry once; then do the task yourself and note the fallback |
140| Auth expired | Stop; ask the user to run `grok login` |
141| 2 fix-up rounds exhausted | Preserve the diff, ask the user for a recovery decision, then finish the task manually if authorized |
142| Dirty tree at dispatch | Refuse; commit/stash first |
143
144## Limitations
145
146- Grok receives the approved task specification; it is a third-party service and should not
147 receive secrets, proprietary material, personal data, or customer data.
148- `--always-approve` allows edits without an interactive approval prompt. It must be limited to
149 a clean, explicitly approved worktree and never substitutes for the orchestrator's review.
150- Model output can be incorrect, insecure, incomplete, or out of scope. Review the diff and
151 run the acceptance checks before accepting any change.
152- This skill does not authorize installations, updates, commits, pushes, deployments, or
153 destructive cleanup.
154
155## Models
156
157Default `grok-4.5`. Add `-m grok-composer-2.5-fast` only for trivial mechanical tasks.
158
159---
160
161**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/grok-build/SKILL.md`
162
163**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/grok-build/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/grok-build/SKILL.md`
thedixitjain