sauerlandtreffi

Cursor Grok Workflow — AI skill for Claude Code

AI community

Hand the grunt work to ten Cursor agents at once.

How to install Cursor Grok Workflow

This entry records only its repository, not the path inside it, so there is no exact command to give. Open sauerlandtreffi/Cursor-Grok-Workflow and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Cursor Grok Workflow does

Hand the grunt work to ten Cursor agents at once. Keep every decision yourself. A Cursor Agent CLI fan-out skill for Claude Code and Codex — built around the fact that the model will report success for work it never performed.

Alternatives in AI

  • Fact Checker — Verify claims and facts with sources 653 ★
  • Embeddedskills — An open-source collection of embedded development and debugging skills for Claude Code, Copilot, TRAE, and oth 593 ★
  • Skillport — Bring Agent Skills to Any AI Agent and Coding Agent — via CLI or MCP 408 ★

README

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` ⇒