К основному содержанию
скилл CX Codex

build · juliusbrussee — скилл для Claude Code: что делает и как установить

Выполняет задачи из SPEC.md по схеме «план, реализация, проверка». Подходит для работы с конкретной задачей §T или очередью незавершённых задач.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add JuliusBrussee/cavekit --skill build -a claude-code
Открыть на GitHub

Что делает build

Скилл читает SPEC.md, выбирает задачу §T по аргументу или берёт следующую незавершённую. Перед правками он сверяет затронутые инварианты §V, интерфейсы §I, список файлов и команды проверки. Если SPEC.md нет, скилл предлагает сначала вызвать скилл spec.

Для задач с общими модулями, авторизацией, данными, деньгами или публичным §I он запускает /review. Затем меняет статус задачи в SPEC.md, вносит код и запускает указанную проверку. Для параллельной работы этот скилл не годится: он действует в одном потоке и не создаёт субагентов.

Успешная проверка переводит задачу в статус x и создаёт коммит с целью задачи и ссылками на §V. При сбое теста или сборки скилл вызывает backprop перед повторной попыткой. Он отделяет ошибку кода от ошибки спецификации или неописанного случая; для двух последних сначала вызывает spec.

Какие задачи решает

  • реализовать выбранную задачу §T из SPEC.md
  • взять следующую незавершённую задачу
  • связать инварианты §V с именованными тестами
  • запустить /review для задачи с высоким риском изменений
  • вернуть задачу к уточнению спецификации после сбоя проверки

Примеры запросов агенту

  • build §T.3
  • build --next
  • Запусти сборку всех незавершённых задач из SPEC.md.

Как установить build

1Через Skills CLI (Vercel)

npx skills add JuliusBrussee/cavekit --skill build -a claude-code

2Вручную: положить файлы

~/.claude/skills/build/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/build/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора9

caveman Скилл переводит записи в SPEC.md и рядом с ним на телеграфный «пещерный» язык. Токенов уходит примерно на 75% меньше, чем в обычной прозе. CX Codex +1 2 800установок check Скилл читает SPEC.md и сравнивает его с кодом. Ничего не пишет, только сообщает о расхождениях по степеням важности. CX Codex +1 2 700установок spec Создаёт и обновляет файл SPEC.md в корне проекта, фиксируя цели, инварианты, задачи и найденные баги в лаконичном стиле caveman. CX Codex +1 2 700установок backprop Скилл превращает исправление багов в обновление спецификации SPEC.md. Агент находит причину ошибки, формулирует проверяемый инвариант, пишет падающий тест и фиксирует всё одним коммитом. CX Codex +1 2 600установок grill Задаёт точечные вопросы по одному за раз, чтобы отсеять слабые места в идее фичи до составления спецификации. CX Codex +1 793установок review Проводит враждебную ревизию спецификации до того, как написан код. Строит скептичного рецензента и пытается опровергнуть план, а не подписать его. CX Codex +1 787установок research Собирает факты из документации и RFC во внешний журнал §R со ссылками на источники, чтобы агент не выдумывал поведение библиотек. CX Codex +1 786установок deepen Находит поверхностные модули с громоздкими интерфейсами и проектирует глубокую архитектуру. Запускается, когда тесты зелёные и остался неизрасходованный бюджет токенов. CX Codex +1 770установок

Другие версии build

Похожие

om-auto-create-pr-loop open-mercato Создаёт PR по развёрнутому описанию задачи, ведёт план и фиксирует прогресс по шагам. Нужен для длинных изменений, которые важно продолжать без потери контекста. CX Codex +1 3 700установок build-mvp BuilderOS Проходит по всем задачам роадмапа по порядку: реализует, тестирует, отмечает галочки и в конце делает первый коммит. CX Codex +1 1 600установок build-graph tirth8205 Собирает или обновляет граф знаний для code review в репозитории. Нужен при первой настройке, смене ветки или крупном рефакторинге. CX Codex +1 1 300установок bug-hunt-swarm Dimillian Ищет первопричину багов параллельно через субагентов и ранжирует версии. Нужен для регрессий, сбоев и нестабильного поведения без правок кода. CX Codex +1 713установок debugging-and-error-recovery addyosmani Скилл ведёт агента по шагам от воспроизведения ошибки до проверки исправления. Подойдёт, когда падают тесты, ломается сборка или поведение не совпадает с ожиданиями. CX Codex +1 62 800установок no-mistakes kunchenguid Проверяет изменения через цепочку ревью, тестов, линтинга, документации и CI перед отправкой в настроенную ветку. Подходит для валидации задачи после её выполнения. CX Codex +1 5 600установок

Рядом в теме «Настройка агента: память, контекст, субагенты»

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →

Вопросы о build

Как установить build в Claude Code?

Выполните npx skills add JuliusBrussee/cavekit --skill build -a claude-code, затем повторите npx skills add JuliusBrussee/cavekit --skill build -a claude-code. Файл скилла размещается в ~/.claude/skills/build/SKILL.md.

Что делает build?

Скилл планирует и выполняет задачи из SPEC.md, а затем проверяет результат указанной командой теста, сборки или линтера. Он отмечает статус задачи и создаёт коммит после успешной проверки.

Что происходит, если тест или сборка завершаются с ошибкой?

build вызывает backprop до новой попытки. Если причина в спецификации или неописанном граничном случае, сначала запускается spec для обновления §V и §B.

Исходный текст

SKILL.md · MIT
---
name: build
description: |
  Plan-then-execute implementation against SPEC.md. Native single-thread
  loop, no sub-agents. On test or build failure, auto-invokes the backprop
  skill before retrying — a failed verification always considers whether
  a new §V invariant would prevent recurrence. Triggers when the user asks
  to build, implement, execute the spec, or tackle a specific §T task
  (`build §T.3`, `build --next`, `implement next task`, `run the build`).
  Expects SPEC.md to exist; if not, defers to the spec skill.
---

# build — implement spec

Single-thread native plan→execute. You are main Claude. No swarm.

## LOAD

1. Read `SPEC.md`. If missing → tell user to invoke the spec skill first. Stop.
2. Read `FORMAT.md` once if not loaded.
3. Read §R if present — external facts the build must honor, ⊥ re-derive or contradict.
4. Parse invocation args:
   - `§T.n` → that task only
   - `--next` → lowest-numbered row with status `.` or `~`
   - `--all` or empty → every `.` row in §T order

High blast radius (shared module, auth, data, money, public §I)? Run `/review` first. Trivial & reversible? Skip planning ceremony, just do step EXECUTE.

## PLAN

Native plan mode — you delegate to it, you do not reinvent task breakdown. For chosen task(s):

1. Cite every §V invariant that applies. Plan must respect all.
2. Cite every §I interface touched. Plan must preserve shape.
3. List files to create / edit.
4. **Verification contract** — name the EXACT test(s) / acceptance criteria that
   prove each §V touched. Which test, not "add tests". "Do TDD" alone backfires;
   the spec says *what to check*. Each §V touched → a named test that fails first.
5. Name verification command (test, build, lint) — this is the external oracle. Green = done; ⊥ "looks done".

Show plan. Wait for user OK unless auto mode.

## EXECUTE

Per task in order:

1. Flip §T.n status cell `.` → `~`. Just write to SPEC.md.
2. Edit code per plan.
3. Run verification command.
4. **Pass** → flip `~` → `x`. Next task.
5. **Fail** → invoke backprop skill. Do NOT retry blindly.

## FAIL → BACKPROP

On test/build failure:

1. Read failure output.
2. Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case?
3. If (a) → fix code, re-run. No spec change.
4. If (b) or (c) → invoke spec skill with `bug: <cause>` first, let it update §V and §B, then resume build against updated spec.

Rule: never silently fix root-cause without considering backprop. §B is the memory that stops recurrence.

## WRITE POLICY

- Only flip §T status. No other SPEC.md edits from build.
- Other spec edits → invoke spec skill.
- Commit after each §T completes. Message: `T<n>: <goal line>` + §V cites.

## VERIFICATION

Task `x` only if:
- Verification command (the oracle) exits 0.
- Every §V touched has its named test from the verification contract, and it passes.
- No §V invariant regressed (run full test suite at end).

## NON-GOALS

- No sub-agents. No parallel workers. Main thread only.
- No progress dashboards. `cat SPEC.md | grep §T` is the dashboard.
- No speculative work beyond chosen task scope.

© JuliusBrussee · MIT · JuliusBrussee/cavekit

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой