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.
SkillScore77Maintained
Automatic
◆Coding pack
Last verified 8/23/2026
What it changes
Passed 15 of 19 test cases with the skill, and 7 of 19 without it.
Without skill36%
With skill77%
Checks it passed that the model alone missed
Specifies --max-turns 30
Specifies the --check flag
Selects grok-4.5 as the default model
and 8 more in the full report
11 fixed6 passed either way3 still failing2 broke
Pass-rate lift
+41 pp
Tokens
+7%
Agent turns
0%
Response time
-67%
Model gemini-3.6-flashMeasured 8/23/2026v117 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
When running multiple independent tasks concurrently using Grok CLI across isolated feature branches, what CLI argument specifies the target worktree name?
What was checked, without and with the skill
Checked
Without skill
With skill
Specifies the argument format --worktree=<task-slug>
Missed
Passed
case-22 · gemini-3.6-flash · 8/23/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md126 lines2 files
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.