Cursor Grok Workflow

Cursor-Grok-Workflow (`cursor-w`)

**Hand the grunt work to ten Cursor agents at once. Keep every decision yourself.**

This is a skill for coding agents — Claude Code, Codex, or any harness that can read a `SKILL.md` and run a Node script. It lets your agent dispatch up to 10 Cursor Agent CLI subagents in parallel (running Grok), each with its own task, and then verify what they actually did.

Ported from [grok-w](https://github.com/sauerlandtreffi/grok-w), which does the same thing with the xAI Grok Build CLI.

---

Why this exists

Fanning out work to subagents is easy. Trusting the answers is not.

The model will report success for work it never performed. Not occasionally, and not in a way that looks like failure.

grok-w measured this on grok-4.6 across 22 real tasks: a `node --version` it never ran (and got wrong), files it claimed to have written that were never on disk, facts "extracted" from a file it never opened. Every one came back schema-valid, confident, and `status: ok`.

So this is not a thin fan-out wrapper. **The verification is the product.**

The tell is mechanical, and Cursor makes it directly observable: its `stream-json` output emits an event per tool call, so the runner counts them.

**A task that needed to look at the world, and made zero tool calls, made its answer up.**

The runner flags that as `suspectNoToolCall`. The doctrine treats a flagged result as fabricated until you prove otherwise — by opening the files and running the proof command yourself.

**A second tell had to be added for Cursor**, and it is the more useful one. Measured live: a shell command dispatched without `--force` comes back `rejected` — five attempts, every one refused — while the process still exits **0** with `subtype: "success"` and `is_error: false`. The task made five tool calls, so the zero-tool-call flag never fires, and nothing in the machine-readable result says the work was blocked. Only the event stream knows:

**`rejectedToolCalls > 0` ⇒