lead — скилл для Claude Code: управление проектом как лид
Скилл для организации работы по проекту через очередь задач. Лид пишет бриф, отправляет его свежему агенту Opus в Herdr, проверяет результат и ведёт запись — цикл работает без остановок.
npx skills add robertguss/claude-code-toolkit --skill lead -a claude-codeЧто делает lead
lead организует работу в режиме лид-воркер: вы держите суд, AI пишет код. Система читает два файла в корне проекта — LEAD.md (параметры: имя воркера, модель, команда тестирования) и HANDOFF.md (состояние очереди) — и движется по циклу: бриф, свежий агент, наблюдение, проверка, запись.
Цикл никогда не останавливается, чтобы спросить. Вопрос к человеку — это ваше решение, которое записывается в журнал решений, а работа продолжается. Свежий агент запускается на каждый бриф и видит только ориентацию, область записи, части работы и условия завершения. Вы смотрите пане каждые 15–25 минут, проверяете тесты, пишете собственные клиенты в scratchpad для входов, которые бриф не назвал, и одобряете или отменяете решения воркера.
Зависит от Herdr и Claude Code. Требует ручной настройки LEAD.md и HANDOFF.md перед первым запуском — см. references/setup.md в репозитории.
Какие задачи решает
- Вести очередь задач для проекта, не останавливая работу на вопросы
- Разделить судейскую функцию (человек) и исполнительную (AI)
- Записывать решения и проверять работу агента собственными тестами
- Запускать свежий агент на каждую задачу без накопления контекста
Примеры запросов агенту
- Запустите лид-цикл: прочитайте
LEAD.md, возьмите первую задачу из очереди вHANDOFF.md, напишите бриф - Отправьте бриф свежему агенту в Herdr:
herdr agent start lead --kind claude --pane work --timeout 60000 - Каждые 15–25 минут проверьте статус:
herdr agent get leadиherdr pane read work --lines 40
Как установить lead
1Через Skills CLI (Vercel)
npx skills add robertguss/claude-code-toolkit --skill lead -a claude-code2Вручную: положить файлы
~/.claude/skills/lead/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/lead/
1Через Skills CLI (Vercel)
npx skills add robertguss/claude-code-toolkit --skill lead -a codex2Вручную: положить файлы
.agents/skills/lead/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add robertguss/claude-code-toolkit --skill lead -a cursor2Вручную: положить файлы
.cursor/skills/lead/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install robertguss/claude-code-toolkit lead2Вручную: положить файлы
.github/skills/lead/SKILL.md1Через Skills CLI (Vercel)
npx skills add robertguss/claude-code-toolkit --skill lead -a gemini-cli2Командой платформы
gemini skills install https://github.com/robertguss/claude-code-toolkit --path skills/leadВручную: положить файлы
.devin/skills/lead/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add robertguss/claude-code-toolkit --skill lead -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о lead
Как установить lead для Claude Code?
Выполните в терминале npx skills add robertguss/claude-code-toolkit --skill lead -a claude-code, затем откройте файл ~/.claude/skills/lead/SKILL.md. Для других платформ замените флаг -a на codex, cursor, gemini-cli или opencode.
Зачем нужен lead?
Это система управления проектом, где вы пишете краткие брифы, отправляете их агентам в Herdr (по одному на задачу), проверяете результаты тестами и собственными пробами, и записываете решения. Цикл работает без пауз на уточнения.
Что такое LEAD.md и HANDOFF.md?
LEAD.md — стабильная конфигурация проекта (имя воркера, модель, команда тестирования, где хранятся брифы). HANDOFF.md — состояние очереди и история решений, которую вы переписываете в каждой паузе. Обе читаются из файла CLAUDE.md в корне проекта.
Исходный текст
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