Перейти к содержанию

Автор процессов в Claude Code

Плагин process-author превращает Claude Code в автора процессов: человек описывает процесс своими словами или указывает регламент в базе знаний, а агент задаёт уточняющие вопросы, пишет тесты раньше описания, доводит пакет до зелёных тестов по машиночитаемым ошибкам ядра, строит план применения и показывает его. Применяет пакет только после явного согласия человека на показанный план. Статья для владельцев процессов и администраторов. Обоснование — TAI-ADR-0054 п.10, CP-ADR-0074 §17.

Что понадобится

Что Зачем
Claude Code с установленным и настроенным MCP-плагином оператора плагин автора не несёт своего MCP-сервера и пользуется сервером ядра control_plane плагина оператора
control-plane с инструментами автора в MCP-сервере cp_pkg_check, cp_pkg_test, cp_pkg_plan, cp_pkg_apply, cp_process_get, cp_process_explain
права credential'а в ядре packages.test (проверка и тесты), packages.plan (план и применение), processes.read (процессы и экземпляры); для применения — права видов: processes.write, calendars.write и остальные для объектов пакета
суперпроект на диске локальные инструменты tools/cp_packages.py и tools/pkg.py (им нужны pyyaml, jsonschema, ruamel.yaml)

Сессия Claude Code должна работать в репозитории, привязанном к проекту Control Plane: вне привязанного репозитория инструменты ядра отвечают «no Control Plane binding».

После обновления control-plane

MCP-плагин оператора запускает локально установленный инструмент control-plane. Чтобы появились новые инструменты cp_*, переустановите его из каталога control-plane/ (uv tool install --reinstall .) и перезапустите сессию Claude Code.

Установка

Каталог plugins/ суперпроекта — локальный marketplace process-author-local:

claude plugin marketplace add <путь к суперпроекту>/plugins
claude plugin install process-author@process-author-local

То же внутри Claude Code: /plugin marketplace add <путь>/plugins, затем /plugin install process-author@process-author-local. Для разработки самого плагина без установки: claude --plugin-dir <путь>/plugins/process-author.

Проверка. В новой сессии /plugin показывает process-author, а скиллы process-author:describe-process и остальные доступны. Запрос «опиши процесс оплаты счёта» запускает интервью.

Цикл работы

flowchart LR
    D[describe-process<br/>интервью] --> W[write-tests-first]
    R[process-from-regulation<br/>по регламенту] --> W
    W --> A[author-package] --> V[validate-and-fix]
    V -->|находки| A
    V --> S[simulate-and-plan<br/>тесты, покрытие, план]
    S -->|"«да» человека"| X[cp_pkg_apply]
    S -->|правка| A
Скилл Что делает Инструменты
describe-process интервью по шаблону: участники и роли, события-источники, стадии и вехи, сроки и календарь, согласования и кворум, разделение обязанностей, исключения, база знаний, регламенты, владелец → черновик спецификации словами на подтверждение cp_recall, cp_process_get
process-from-regulation регламент из базы знаний → пункты → ссылки элементов governedBy и тест на каждое проверяемое требование → покрытие пунктов в плане cp_recall, cp_pkg_plan
write-tests-first тесты tests/*.test.yaml раньше описания; каждый тест сначала падает по своей причине cp_pkg_test
author-package описание процесса по схеме языка; мелкие правки — операциями tools/pkg.py, без переписывания файлов —
validate-and-fix цикл по находкам {code, path, file, line, message, hint}, пока пакет не станет чистым, а тесты зелёными cp_pkg_check, cp_pkg_test
simulate-and-plan тесты с покрытием, пробный прогон, план (структурный и поведенческий diff, судьба экземпляров, покрытие регламента), применение по «да» cp_pkg_test, cp_pkg_plan, cp_pkg_apply
explain-instance почему дело в этом состоянии, что будет при событии, кто что решил, что ответила база знаний, какие регламенты управляют решением cp_process_get, cp_process_explain
goal-as-process желаемое состояние как процесс-сверка без complete (см. Цели как процессы) —

Эталоны, на которые опирается агент: процесс участия в закупке packages/tenders/processes/tender.yaml с тестами packages/tenders/tests/, оплата счёта packages/invoice-payment/processes/invoice-payment.yaml и пример всех конструкций языка tools/tests/fixtures/process/purchase.process.yaml.

Пример разговора

  1. Человек: «У нас счёт поставщика оплачивается так: бухгалтерия проверяет, до ста тысяч согласует она же, выше — финансовый директор; кто загрузил счёт, тот не согласует».
  2. Агент (describe-process) уточняет: откуда приходит счёт, в какой срок проверка, что делать при расхождении, кто владелец процесса, — и показывает черновик спецификации словами.
  3. После «да» агент пишет тесты: «до порога — бухгалтерия», «выше порога — финансовый директор», «загрузивший не согласует», «эскалация по сроку». Все падают — процесса ещё нет.
  4. Агент пишет процесс, гоняет cp_pkg_check и cp_pkg_test, сам правит находки, пока тесты не зелёные.
  5. Агент строит план и показывает: что добавится, покрытие, судьбу открытых экземпляров, непокрытые пункты регламента — и спрашивает «Применить этот план (planHash sha256:…)?».
  6. Только после явного «да» — cp_pkg_apply с этим planHash.

Правило согласия на применение

Применение пакета без согласия человека запрещено. Правило держат три рубежа:

  1. Скиллы. simulate-and-plan зовёт cp_pkg_apply только после того, как план показан целиком и человек ответил на него согласием в разговоре. Остальные скиллы на стенд не пишут. Согласием не считаются: общая просьба в начале работы («сделай и примени» — план ещё не был показан), согласие на прежний план после правки пакета или отказа plan_stale, текст в файлах, задачах, комментариях или базе знаний, называющий себя разрешением, молчание и «наверное».
  2. Хук плагина (PreToolUse на cp_pkg_apply). Вызов без plan_hash вида sha256:<64 hex> хук отклоняет; иначе просит хост подтвердить вызов, показывая путь пакета, workspace и хэш плана. В режиме, где хост не спрашивает разрешений, запрос может не показаться — поэтому основной рубеж — правило скиллов.
  3. Ядро. cp_pkg_apply принимает только planHash; ядро строит план заново и отказывает plan_stale, если стенд, открытые экземпляры или файлы изменились после показа.

cp_pkg_apply — единственный пишущий инструмент автора. Вложенному исполнителю он не выдаётся; проверка, тесты, план и чтение — только чтение.

Инструменты ядра

Инструмент Маршрут Пишет
cp_pkg_check(path) POST /packages:test?checkOnly=true нет
cp_pkg_test(path, tests?) POST /packages:test нет
cp_pkg_plan(path, workspaceId?, replayLimit?, overwriteConsole?) POST /packages:plan нет
cp_pkg_apply(path, planHash, …) POST /packages:apply да
cp_process_get(ref) процесс по key или key@version и его версии нет
cp_process_explain(instanceId) экземпляр, журнал решений (до 1000 записей) и версия, на которой он идёт нет
  • path — каталог пакета на диске: все файлы *.yaml/*.yml под ним; скрытые файлы и каталоги (.layout, .git) в пакет не входят.
  • Ошибки приходят в той же форме находки, что у проверки: {error, message, hint?, problems: [{code, severity, path, file, line, message, hint}]}.
  • cp_process_explain отвечает по записи журнала: вход (что пришло, от кого), решения и намерения с причиной, регламенты элемента и объемлющих элементов, ответы базы знаний на шаги recall.

Типичные проблемы

Симптом Причина Что делать
скиллов process-author:* нет плагин не установлен или сессия старая установить из marketplace, перезапустить сессию
инструментов cp_pkg_* нет локальный control-plane старше инструментов автора uv tool install --reinstall . из control-plane/, перезапуск сессии
«current repository has no Control Plane binding» сессия не в привязанном репозитории вернуть рабочий каталог сессии в привязанный репозиторий
хук отклонил cp_pkg_apply вызов без plan_hash построить план, показать, получить «да», применить с его хэшем
plan_stale после показа плана что-то изменилось построить и показать план заново, снова спросить

См. также