grok-implement
Skill3 starsChanged 7 days agoMITView on GitHub
Dispatch an implementation task to xAI's Grok Build CLI (Grok family) in an isolated worktree. Use when the user asks Grok/Grok Build to implement something, or when the paid pools' other families are reserved for review and a Grok write leg keeps the cross-family accounting clean.
In this repository15 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- agy-adversarial-reviewSkill
- agy-implementSkill
- claude-adversarial-reviewSkill
- claude-implementSkill
- codex-adversarial-reviewSkill
- codex-implementSkill
- configSkill
- cursor-adversarial-reviewSkill
- cursor-implementSkill
- dev-leadSkill
- grok-adversarial-reviewSkill
- opencode-adversarial-reviewSkill
- opencode-implementSkill
- quota-setupSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Every write leg gets its own worktree, without exception — same rule, same helpers, same reasons as the other families:
- Distinctive: line 77
Check the refs snapshot, verify the worktree, then the lead reviews and commits:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Implement via grok (Grok Build)
A paid-pool write leg, tier peer of codex-implement and agy-implement.
Its output is Grok-family work: the review gate for anything it writes
must come from a different model family — that is the suite's headline
cross-family rule, and it is the main reason to spend this pool on
implementation at all (it frees the GPT/Gemini/Claude legs to review).
Before the first run of a session
Read references/grok-runtime.md.
The items that bite the write role hardest: the machine's config.toml may
carry a global always-approve default (state the posture explicitly, never
inherit it), the sandbox is kernel-gated and silently unenforced on old
kernels, and this adapter has zero calibration-journal rows of its own
(the Grok-family rows in cursor-runtime.md were served through cursor) —
first dispatches are calibration runs, verified accordingly.
Worktree, snapshot, then dispatch
Every write leg gets its own worktree, without exception — same rule, same helpers, same reasons as the other families:
RUN_DIR=$(mktemp -d "${TMPDIR:-/tmp}/grok-implement.XXXXXX") # FIRST — the snapshot lands here
BASE=$(git rev-parse HEAD) # from a clean checkout, recorded before anything
WORKTREE=../<repo>-grok-<short-task-slug>
git worktree add -b grok/<short-task-slug> "$WORKTREE" "$BASE"
# The helper lives in the SUITE's tree, cwd is the TARGET repo — a bare
# `scripts/…` resolves against the target and exits 127.
DEV_LEAD=${DEV_LEAD_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/dev-lead/dev-lead/* 2>/dev/null | sort -V | tail -1)}
[ -x "$DEV_LEAD/scripts/snapshot-refs.sh" ] || { echo "dev-lead root unresolved — set DEV_LEAD_ROOT to your checkout"; exit 1; }
"$DEV_LEAD/scripts/snapshot-refs.sh" save "$WORKTREE" "$RUN_DIR/remote-refs.before" # push-detection baselineThe snapshot matters MORE here than on agy: grok's shell tool is unrestricted inside its permission mode, so the no-push rule is instruction level on this adapter (state it in the task prompt), and the fail-closed ref check at handoff is what turns "surely it didn't push" into evidence, either way.
Launch
# Write the task prompt to "$RUN_DIR/task.md" in its own FOREGROUND step.
cd "$WORKTREE" && \
grok --prompt-file "$RUN_DIR/task.md" \
-m grok-4.6 \
--effort medium \
--permission-mode bypassPermissions \
--sandbox workspace \
--disallowed-tools "Agent" \
--no-memory --verbatim \
--max-turns 80 \
--output-format plain > "$RUN_DIR/impl.out" 2>&1--permission-mode bypassPermissionsis stated, not inherited — the config default may already say the same thing, and that is exactly why the flag is on the command line: a run log must show its posture (runtime file, config trap).--sandbox workspaceconfines writes to the worktree + temp dirs on kernels that enforce it (documented); on older kernels it is a warned no-op and the worktree boundary + refs snapshot are the real containment.--disallowed-tools "Agent"— one delegate, one worktree; subagents inherit always-approve and answer to nobody's plan (runtime file).- Effort:
mediumfor routine implementation; spendhighon review legs first when the weekly pool is tight — review leverage is higher.
Handoff
Check the refs snapshot, verify the worktree, then the lead reviews and commits:
"$DEV_LEAD/scripts/snapshot-refs.sh" check "$WORKTREE" "$RUN_DIR/remote-refs.before" || exit 1
git -C "$WORKTREE" status --porcelain=v1
git -C "$WORKTREE" diff "$BASE" --statThe helper exits nonzero on a remote-ref delta, and || exit 1 makes that
failure terminal for this handoff. Do not replace it with a second snapshot
and a raw diff, which can be noticed but accidentally continued past.
Whether grok leaves work committed or uncommitted in the worktree is UNVERIFIED (runtime file) — expect either, and treat the lead's own verification pass as the merge gate regardless: build/tests run by the lead, in the worktree, before anything is called done. The change then goes to a reviewer from a different model family — never a Grok reviewer for a Grok implementation.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

