grok-build

name	grok-build
description	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.
category	agent-orchestration
risk	critical
source	https://github.com/sanjay3290/ai-skills/tree/main/skills/grok-build
source_repo	sanjay3290/ai-skills
source_type	community
date_added	2026-07-09
author	sanjay3290
tags	["grok","delegation","code-generation","xai"]
tools	["claude","cursor","gemini"]
license	Apache-2.0
license_source	https://github.com/sanjay3290/ai-skills/blob/main/LICENSE

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)

1. grok update --check --json — if updateAvailable is true, tell the user. Run grok update only after explicit approval, then 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.