PAUL — плагин
PAUL ведет разработку в Claude Code циклом из плана с критериями приемки, выполнения с проверкой задач и обязательного закрытия
- 1 255 ★ репозитория
- Последний коммит
- MIT
Расширенный доступ
Почему такой уровень
- Установщик пишет команды и справочники в каталог `.claude`, домашний или проектный, и создает в проекте папку `.paul`
- Команды поручают агенту править файлы проекта по плану; границы изменений задаются в плане, но обеспечиваются только самим агентом
Установка
- Работает в
Ручная установка
npx paul-frameworkУстановщик спросит, ставить глобально или в текущий проект. Проверка: /paul:help.
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- Установщик пишет команды и справочники в каталог `.claude`, домашний или проектный, и создает в проекте папку `.paul`
- Команды поручают агенту править файлы проекта по плану; границы изменений задаются в плане, но обеспечиваются только самим агентом
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
PAUL — набор из 26 слэш-команд для Claude Code, который превращает работу над проектом в повторяющийся цикл план, выполнение, закрытие. Команда `npx paul-framework` спрашивает, куда ставить, и копирует файлы в папку `commands/paul` и каталог `paul-framework` внутри `.claude`: в домашней (для всех проектов) или в папке текущего проекта. Проверить установку можно командой `/paul:help`. В проекте `/paul:init` проводит опрос, адаптированный под тип работы (приложение, кампания, рабочий процесс), и собирает заполненный `PROJECT.md`. Рядом в папке `.paul` лежат `ROADMAP.md`, `STATE.md` с позицией в цикле, `paul.toml`, `ledger.toml` и папка `phases` с планами и итогами. Команда `/paul:plan` выбирает размер плана: быстрая правка, стандартный план из 2–5 задач или сложный из 6 и больше задач, который PAUL советует разделить. В плане есть цель, критерии приемки в формате `Given`, `When`, `Then`, задачи с файлами, проверкой и условием готовности и границы с перечнем файлов, которые менять нельзя. `/paul:apply` выполняет утвержденный план. После каждой задачи PAUL заново читает результат и сверяет с описанием задачи и критериями приемки. Задача получает один из четырех статусов: `DONE`, `DONE_WITH_CONCERNS`, `NEEDS_CONTEXT` или `BLOCKED`. Затем `/paul:unify` сравнивает план с фактом, пишет `SUMMARY.md`, фиксирует решения и отложенные вопросы и обновляет `STATE.md`. По `/paul:resume` сессия продолжается с одного предложенного шага.
Для кого. Для разработчиков и руководителей проектов, которые ведут работу в Claude Code на многих сессиях и хотят заранее прописывать критерии готовности, а не выяснять их по ходу.
Подходит, если
- Проект растет по фазам, и между сессиями нужно сохранять позицию в плане, принятые решения и список отложенных вопросов
- Агент отчитывается о готовности, а вы хотите, чтобы каждая задача сверялась с критериями приемки до закрытия плана
- Надо быстро внести одну правку в одном файле, но с тем же порядком: цель, критерий, задача, закрытие
- Работа не сводится к коду: кампания, воронка, рассылка или автоматизация, где тоже нужны этапы и критерии
- Перед планом вы хотите обсудить подход и посмотреть допущения агента командами `/paul:discuss` и `/paul:assumptions`
Не подходит, если
- Вы работаете не в Claude Code: установщик кладет файлы только в папку `.claude`
- Нужна разовая задача на несколько минут без плана и журнала: цикл потребует заполнить `.paul` и закрыть план
- Вы хотите разносить реализацию по субагентам: PAUL ведет разработку в одной сессии, а субагентов оставляет для исследования
- Нужен набор, построенный вокруг писаной спецификации с перечнем требований и дизайна: для такого подхода в каталоге есть OpenSpec
Пример запроса к агенту
Поставь PAUL в этот проект, запусти init и составь план первой фазы так, чтобы у каждой задачи был критерий приемкиОграничения
- Проект рассчитан на Claude Code, поддержку других агентов автор не заявляет.
- Цикл работает, только если план закрыт командой `/paul:unify`: автор называет это обязательным шагом, без него состояние в `STATE.md` расходится с реальностью.
- Реализация идет в одной сессии, а субагенты запускаются для исследований. Поэтому крупные работы стоит резать на планы: сложным считается план от 6 задач, и PAUL сам предлагает его разделить.
- Команда `/paul:status` помечена как устаревшая, вместо нее предлагается `/paul:progress`.
- Для установки нужен Node.js 16.7 или новее. Интеграция с BASE v2 (отдельный бинарник на Rust, который читает `.paul/paul.toml` и `ledger.toml`) необязательна, PAUL работает и без нее.
- Лицензия MIT, версия пакета 1.4.0.
Как отключить. Удалите папки `commands/paul` и `paul-framework` из каталога `.claude`, куда ставили (в домашней папке или в проекте), и папку `.paul` в проекте, если журнал не нужен.
Частые вопросы
Как структурировать разработку в Claude Code по плану и критериям приемки?
Поставьте PAUL командой `npx paul-framework`, запустите `/paul:init`, затем `/paul:plan`. План получит критерии в формате `Given`, `When`, `Then`, задачи со ссылками на эти критерии и границы изменений. После утверждения `/paul:apply` выполняет задачи, а `/paul:unify` закрывает план.
Чем быстрая правка отличается от стандартного и сложного плана?
`/paul:plan` сам определяет размер. Быстрая правка (один файл, одно изменение) сжимается до цели, одной задачи и одного критерия, цикл при этом проходит целиком. Стандартный план включает 2–5 задач с границами и проверочным списком. Сложный, от 6 задач, PAUL рекомендует разделить.
Что значат статусы DONE_WITH_CONCERNS и NEEDS_CONTEXT?
Это два из четырех статусов задачи. `DONE_WITH_CONCERNS` означает, что задача сделана, но у агента остались сомнения для проверки. `NEEDS_CONTEXT` означает, что не хватает информации. Еще есть `DONE` без замечаний и `BLOCKED` для структурной помехи.
Что делать, если проверка или приемочное тестирование нашли проблему?
PAUL сначала определяет причину: изменилось намерение, ошибка в спецификации или код не соответствует верному плану. В первом случае фаза планируется заново, во втором правится план, в третьем код правится на месте. Для замечаний приемки есть команда `/paul:plan-fix`.
Можно ли использовать PAUL для работы, не связанной с кодом?
Да, автор называет сценарии с кампаниями, воронками, рассылками и автоматизациями. Для них опрос в `/paul:init` подстраивается под тип проекта (приложение, кампания или рабочий процесс).
Как поставить PAUL только в один проект?
Запустите `npx paul-framework --local` или выберите локальную установку в диалоге. Файлы попадут в `./.claude` текущей папки. Для всех проектов служит `--global`, он пишет в `~/.claude`.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
ПлагиныПлагин для Claude Code: 39 команд для PR, ревью, коммитов и спецификаций, девять ролей экспертов и хуки, восемь языковых версий
Goal Workflow
goal-workflow
19 скиллов для Claude Code: PRD, спецификация, задачи в GitHub Issues, пакетная реализация с ревью и слияние pull request, плюс рефакторинг и диаграммы
Плагин из трех скиллов для крупных задач разработки: анализ проекта, разбивка на фазы с задачами в GitHub Issues, параллельные агенты и ревью кода
Процесс разработки из связанных скиллов для Claude Code и Codex: план, реализация, ревью, тесты, коммит и PR
Универсальный плагин рабочего процесса для Claude Code: 7 агентов, 26 команд, 14 скиллов и 14 хуков для любого проекта
Плагины Claude Code с рецептами разработки: согласовать результат, спроектировать, реализовать с проверками и провести независимое ревью
Сравнение с похожими
Записи с тем же главным запросом: чем они отличаются.
| Запись | Официальный | Звезды репозитория | Главное отличие |
|---|---|---|---|
| PAUL (эта запись) | нет | 1 255 | |
| GSD Core | нет | 10 814 | цикл обсуждение, план, выполнение, проверка и релиз в свежих контекстах, PAUL держит работу в одной сессии и требует закрытия плана |
| Spec Kit | нет | 142 610 | набор GitHub с CLI specify и ходом от принципов к реализации, PAUL строится вокруг критериев приемки и состояния в STATE.md |
| OpenSpec | нет | 72 863 | сначала предложение, требования и дизайн, потом код, PAUL работает циклом план, выполнение, закрытие |
Коротко о README
В репозитории лежит установщик `bin/install.js` и каталог `src` с командами, шаблонами, справочниками, рабочими процессами и правилами. На главной странице описаны три принципа (закрытие каждого плана, работа в одной сессии, критерии приемки), порядок установки и сценарий из пяти команд. Дальше идут таблица всех команд по группам, структура папки `.paul`, пример файла плана с XML-разметкой и разделы о проверке задач и философии. Отдельный файл сравнивает PAUL с GSD.