agentleFS
robertgussrobertguss/claude-code-toolkit/skills/lead/SKILL.md

lead

Skill118 starsChanged 4 months agoMITView on GitHub

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…

  • Installs packages

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use reflect, technical-writing and 4 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Microsoft AzureSkill

    reflect

    Learning capture system that extracts HIGH/MED/LOW confidence patterns from conversations to prevent repeating mistakes. Use after user corrections ("no", "wrong"), praise ("perfect", "exactly"), or when discovering edge cases. Complements .squad/agents/{agent}/history.md and .squad/decisions.md.

    Also in 4 projects that use this

  • VercelSkill

    technical-writing

    Write, edit, review, or audit user-facing documentation for the eve repository. Use for changes under docs/, documentation tied to eve APIs or CLI behavior, docs work based on Slack or support feedback, and requests to make eve docs clearer, more natural, or less AI-patterned while verifying claims against current source, tests, CLI help, public releases, and repository conventions.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    design

    Design rules and conventions for the API Center Portal. Use when editing detail pages, card components, badges, layout, navigation, sidebars, or headers. Covers badge styling, metadata placement, page navigation patterns, and layout alignment.

    Also in 3 projects that use this

  • photon-groveSkill

    unslop

    Detects and rewrites generic, overly polished, or AI-sounding prose while preserving meaning. Use when the user asks to "unslop", humanize, de-AI, tighten, or review whether writing sounds generated.

    Also in 3 projects that use this

  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 4 projects that use this

  • VercelSkill

    setup

    Set up Vercel CLI and project configuration. Use when the user says "set up Vercel", "configure Vercel", "link to Vercel", or "vercel init".

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 13 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

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

    line 23
  2. Very specific:

    Read LEAD.md, then HANDOFF.md, then whatever HANDOFF.md says to read.

    line 28
  3. Very specific:

    Run herdr agent list and herdr pane list.

    line 29
  4. Very specific:

    Write one page at the brief location LEAD.md names, from assets/brief.md: Orientation (what a fresh session must read and why this step …

    line 55
  5. Very specific:

    Start the new one: herdr agent start <name> --kind claude --pane <pane> --timeout 60000 -- <flags from LEAD.md>.

    line 76
  6. Very specific:

    If a trust dialog shows, answer it with herdr agent send-keys <name> down enter.

    line 78
  7. Distinctive:

    Read the pane like a teammate's screen:

    line 90
  8. Distinctive:

    Read the report's "Decisions the brief did not cover" and rule on each: ratify it, or overturn it with a follow-up brief.

    line 124

“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “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

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, 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: 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 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: 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.

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.