agentleFS
aarontzengaarontzeng/dev-lead/skills/grok-implement/SKILL.md

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.

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
  1. Distinctive:

    Every write leg gets its own worktree, without exception — same rule, same helpers, same reasons as the other families:

    line 26
  2. Distinctive:

    Check the refs snapshot, verify the worktree, then the lead reviews and commits:

    line 77

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 baseline

The 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 bypassPermissions is 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 workspace confines 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: medium for routine implementation; spend high on 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" --stat

The 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.