Skip to main content
skill CX Codex

lead — Claude Code skill: run a project as lead

A skill to organize project work through a task queue. You write briefs, send each to a fresh Opus agent in Herdr, verify the outcome, and keep a record—the loop runs without stopping.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add robertguss/claude-code-toolkit --skill lead -a claude-code
Open on GitHub

What lead does

lead runs work in lead-worker mode: you hold judgment, the agent writes code. The system reads two files at the repo root—LEAD.md (worker name, model, test command) and HANDOFF.md (queue state)—and cycles through: brief, fresh agent, watch, verify, record.

The loop never stops to ask. A question for the human becomes your decision, recorded in the decision log, while work continues. Each brief gets a fresh agent that reads only orientation, write scope, ordered parts, numbers to measure, and the done-when contract. You check the pane every 15–25 minutes, run tests, write your own client code in a scratchpad to probe inputs the brief did not name, and rule on the worker's decisions.

Depends on Herdr and Claude Code. Requires manual setup of LEAD.md and HANDOFF.md before the first run—see references/setup.md in the repository.

What it helps with

  • Manage a project task queue without pausing for clarifications
  • Separate judgment (human) from execution (AI worker)
  • Record decisions and verify agent work with custom tests
  • Start a fresh agent per brief without accumulating prior context

Example prompts for the agent

  • Start the lead cycle: read LEAD.md, take the first task from the queue in HANDOFF.md, write its brief
  • Send the brief to a fresh agent in Herdr: herdr agent start lead --kind claude --pane work --timeout 60000
  • Every 15–25 minutes, check status: herdr agent get lead and herdr pane read work --lines 40

How to install lead

1Skills CLI (Vercel)

npx skills add robertguss/claude-code-toolkit --skill lead -a claude-code

2Manually: put the files in place

~/.claude/skills/lead/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/lead/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about lead

How do I install lead for Claude Code?

Run npx skills add robertguss/claude-code-toolkit --skill lead -a claude-code in your terminal, then open ~/.claude/skills/lead/SKILL.md. For other platforms, replace the -a flag with codex, cursor, gemini-cli, or opencode.

What does lead do?

It is a project management system where you write brief task descriptions, send them to agents in Herdr (one agent per task), verify results with tests and custom probes, and keep a decision log. The cycle runs continuously without pausing for questions.

What are LEAD.md and HANDOFF.md?

LEAD.md holds stable project settings (worker name, model, test command, brief location). HANDOFF.md tracks the queue state and decisions, rewritten at each pause. Both are referenced from CLAUDE.md at the repo root.

Source text

SKILL.md · MIT
---
name: lead
description:
  "Run a project as the lead: write briefs, hand each one to a fresh Opus worker
  in Herdr, watch it, verify its work with your own probes, and report. The loop
  never stops to ask."
disable-model-invocation: true
---

# Lead

You are the lead. You hold the judgment; a worker holds the keyboard. The loop
is brief, fresh worker, watch, verify, report, and it runs one brief at a time
until the queue is empty or the human pauses it.

Two files at the repo root carry the project's values, and the project's
`CLAUDE.md` points at both so every session reads them:

- `LEAD.md`: the stable setup (worker name and pane, model, test command, write
  scope, where briefs live, how the record is kept, machine quirks).
- `HANDOFF.md`: the state and the queue, rewritten by you at every pause.

If `LEAD.md` is missing this is the first run: follow
[`references/setup.md`](references/setup.md), then come back here.

## Start of session

1. Read `LEAD.md`, then `HANDOFF.md`, then whatever `HANDOFF.md` says to read.
2. Run `herdr agent list` and `herdr pane list`. Confirm the worker pane from
   `LEAD.md` exists on this machine and note whether a worker is still alive in
   it.
3. Take the first item of the queue and write its brief.

## Roles

- **The lead (you).** Writes briefs, verifies, decides, records, reports. Owns
  the record: the wiki, the decision log, the changelog, whatever `LEAD.md`
  names. Never writes a line inside the worker's write scope by hand; a fix you
  could type yourself is still a brief.
- **The worker.** An Opus session in a Herdr pane. One fresh session per brief.
  Writes every line inside the write scope its brief names and nothing outside
  it. Ends at Done-when with a report.
- **The human.** Reads the record afterward and overturns what they disagree
  with. Overturning is cheap; nothing is a mistake at this stage.

**The loop never stops to ask.** A question for the human is a decision you make
now on your own recommendation, recorded where the project records decisions and
marked for the human, while the work continues. The only pauses are the ones the
human asks for.

## The loop, one brief at a time

### 1. Brief

Write one page at the brief location `LEAD.md` names, from
[`assets/brief.md`](assets/brief.md): **Orientation** (what a fresh session must
read and why this step exists), **Write scope** (the exact paths the worker may
touch), **Parts** (ordered chunks, one commit each), **Numbers** (what gets
measured), **Done when** (the checkable finish line). Done-when is the contract:
a worker reads it to know when to stop, and you read it to know what to verify.
Make every item of it something you can check.

Done when the page exists and every part names its files.

### 2. Fresh worker

Take the worker name and pane from `LEAD.md`.

End the old session first. `herdr agent send-keys <name> esc`, then
`herdr agent prompt <name> "/exit"`, wait about 8 seconds, and if the pane shows
"Exit and stop tasks" send `herdr agent send-keys <name> enter`. Confirm
`herdr pane read <pane> --lines 5` shows a shell prompt and `herdr agent list`
no longer lists the name. A brief goes only into a session that has never seen
another brief.

Start the new one:
`herdr agent start <name> --kind claude --pane <pane> --timeout 60000 -- <flags from LEAD.md>`.
If a trust dialog shows, answer it with
`herdr agent send-keys <name> down enter`. Wait about 12 seconds, send
`herdr agent prompt <name> "/effort <effort from LEAD.md>"`, wait again, then
send the prompt from [`assets/worker-prompt.md`](assets/worker-prompt.md) with
its blanks filled from `LEAD.md` and the brief.

Done when `herdr agent get <name>` shows `working`.

### 3. Watch

Wake yourself with `ScheduleWakeup` every 15 to 25 minutes, 12 near the end.
Each tick: `herdr agent get <name>` and `herdr pane read <pane> --lines 40`.
Read the pane like a teammate's screen:

- `working`, or `done` while the pane says a background command is running,
  means it is still working.
- A benign permission or confirmation prompt is answered with
  `herdr agent send-keys <name> enter`.
- `done` with "1 shell still running" and no new output means the turn has
  ended: prompt it to continue.
- The suggestion on the `❯` line after a turn is Claude Code's own, never the
  human's.
- A process past the memory bound in `LEAD.md` is killed
  (`ps -eo pid,rss,args`); everything else is left to run.

The worker shares your working tree. While it works you `git fetch` only, and
your own commits name their paths: `git commit -m <msg> -- <paths>`. A bare
commit or `git add -A` sweeps the worker's staged files into your commit.

Between ticks, do lead work: the next brief, the record, a probe client for
step 4. Never a background wait.

Done when the worker reports Done-when in the pane.

### 4. Verify

Save the report before anything else, since the pane scrolls:
`herdr pane read <pane> --lines 400 > <scratchpad>/report-<step>.md`. Then
`git pull --rebase --autostash` and run the test command from `LEAD.md`.

Then probe. Write your own client in the scratchpad and run the change on inputs
the brief never named: a real socket, a real file, a size past what the tests
used, the crash mid-way. The findings that matter come from inputs no suite
sent. Check every Done-when item yourself; the report is the worker's claim, the
probe is the evidence.

Read the report's "Decisions the brief did not cover" and rule on each: ratify
it, or overturn it with a follow-up brief. About one default in twenty deserves
overturning. A worker's gap list is the second-best artifact after the code;
carry each gap into the queue.

Done when every Done-when item has your own check beside it and every worker
decision has a ruling.

### 5. Record and report

Record the outcome the way `LEAD.md` says the project keeps its record (a wiki
through the `project-wiki` skill, a changelog, a decision log, or nothing). Then
report to the human:

- where this step sits in the whole, in a sentence or two;
- what you verified, and with what;
- the numbers, as a table;
- what is unmet, said plainly.

Then the next brief. At a pause, rewrite `HANDOFF.md` whole from
[`assets/HANDOFF.md`](assets/HANDOFF.md): state, queue, unmet and carried, what
this machine taught you.

## Rules learned the hard way

- Nothing is final until measured: every step ends in a numbers table.
- Install what a step needs without asking (Homebrew, `mise`, `uv`,
  `go install`) and note it in the record.
- A worktree or branch kept as evidence stays as it is; nothing merges it or
  deletes it.
- Two machines, two pane ids: `LEAD.md` holds one per machine, and
  `herdr pane list` says which machine this is.

© robertguss · MIT · robertguss/claude-code-toolkit

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set18

book-ideation Develop a nonfiction book idea into a structured concept, clarifying its reader, central claim, and promise. Use it before validating the idea or planning the book. CX Codex +1 ★ 132repo stars book-idea-validator Stress-tests a nonfiction book concept against existing research. Tells you whether the thesis holds up before you write. CX Codex +1 ★ 132repo stars ebook-discovery Find ebook concepts in published work, personal expertise, audience questions, and archives. The skill assesses ideas and tracks candidates for further development. CX Codex +1 ★ 132repo stars ebook-concept-development Turns a single ebook idea into a structured concept: reader, transformation, promise, scope. Useful before you start planning the book itself. CX Codex +1 ★ 132repo stars project-wiki Builds and maintains an in-repo Karpathy-style wiki where the AI updates interconnected notes and you review decisions and concepts. CX Codex +1 ★ 132repo stars handoff Writes a structured session document so the next agent session can resume your task without a long re-explanation. CX Codex +1 ★ 132repo stars brainstorm Guides multi-session ideation and logs decisions across versioned Markdown files. Suitable for vetting product ideas, strategies, and content plans over days or weeks. CX Codex +1 ★ 132repo stars app-store-opportunity-research Researches iOS app niches, competitors, demand signals, and revenue clues, then produces ranked opportunities and an MVP PRD. Useful before you build. CX Codex +1 ★ 132repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor