pwj

Prompt file imported from Morvex885/essence-setup-script (.claude/commands/pwj.md). Fill in {{arguments}} before use. Copyright stays with the author.

/pwj — Planner → Worker → Judger flow

Оркестрирует три сабагента (planner → worker → judger) по паттерну Planner-Worker Separation (см. референс). Адаптация под scale bash-проекта: последовательное исполнение, без recursive sub-planners, с двухуровневой оценкой (step + cycle).

Вызов: /pwj <формулировка задачи> или /pwj (попросит формулировку).

Инвариант: главный Claude не редактирует код

Пока /pwj выполняется, главный Claude (тот, кто ведёт оркестрацию в чате) не имеет права вызывать Edit, Write, NotebookEdit на файлы проекта. Все правки кода — только через worker-агента (Agent tool, subagent_type=worker).

Разрешено: чтение (Read, Grep, Glob), оркестрация (AskUserQuestion, Skill, Bash для финальных проверок), вызовы агентов (planner, worker, judger). Правки в plan-файл при активном plan mode (см. шаг 0) — не считаются правкой кода.

Этот инвариант не отменяется контекстом. Запрещённые рационализации:

• «Plan mode только что одобрил подход» → всё равно через worker.
• «Задача очевидно простая, две строки заменить» → всё равно через worker.
• «Я уже всё расписал в голове, worker сделает то же самое» → всё равно через worker. Цена нарушения инварианта (потеря step-level судьи) выше цены лишних 30 секунд на агентский вызов.

Право объявить задачу тривиальной и сделать правки инлайн принадлежит только planner-агенту (он возвращает TRIVIAL: <инструкция>). Сам себе TRIVIAL не выдавай.

Единственное штатное исключение из инварианта — деградация при технических сбоях агентов, описанная в «Замечаниях» (planner недоступен → ручной режим с явным уведомлением пользователя). Сбои worker'а к этому исключению не относятся — там escalation step-level.

Алгоритм оркестрации

Ты — основной Claude в чате, который выполняет /pwj. Действуй строго по шагам.

0. Plan mode pre-check

Перед всем остальным проверь системные reminder'ы текущего хода. Если активен plan mode (есть строка «Plan mode is active. … Plan File Info: …»):

1. Выполни plan mode по его правилам (Phase 1–5): исследование read-only, план в plan-файл, ExitPlanMode. Plan-файл — единственное, что тебе разрешено редактировать в этом режиме.
2. После одобрения пользователем через ExitPlanMode harness выходит из plan mode. Только тогда начинается /pwj-цикл — переход к шагу 1.
3. При вызове planner на шаге 3.1 передай ему сырую формулировку задачи плюс путь к одобренному plan-файлу плюс комментарий: «Пользователь уже одобрил направление. Если есть смысл — сконвертируй plan-файл в формальные шаги; иначе верни TRIVIAL». Планнер сам решит, переиспользовать структуру или собрать шаги заново.
4. Шаг 3.3 (показ плана пользователю) всё равно выполнить — planner мог разбить шаги иначе, чем prose в plan-файле. Если структура совпадает с одобренным планом — это явно отметить, чтобы пользователю было меньше работы.

Если plan mode НЕ активен — шаг 0 пропускается, сразу к шагу 1.

1. Принять задачу

• {{arguments}} — формулировка задачи пользователя.
• Если пусто — попроси одну строку: «Сформулируй задачу одной строкой, например: /pwj добавить функцию X в common/common.sh и unit-тест на неё».

2. Инициализация cycle

cycle = 1
MAX_CYCLES = 2
MAX_ATTEMPTS = 3
cycle_diagnosis = null
worker_summaries = {}   # step_n → краткое summary тронутых файлов + 1 строка

3. Cycle loop

Повторяй пока cycle ≤ MAX_CYCLES:

3.1. Вызов planner

Через Agent (Task) tool, subagent_type=planner. Prompt:

• Если cycle == 1 — только формулировка задачи.
• Если cycle > 1 — формулировка задачи + блок CYCLE DIAGNOSIS: с диагнозом от предыдущего cycle-judger. Не передавай worker-отчёты первого cycle — это fresh start (из референса: «each cycle should start fresh to combat drift»).

3.2. Развилки на ответе planner

• TRIVIAL: <инструкция> — выполни инструкцию сам (без worker/judger-цикла). Кратко отчитайся, что сделал. Перейди к шагу 4 (/preflight).
• CLARIFY: ... — задай вопросы пользователю через AskUserQuestion. Завершись (новый /pwj запустит заново).
• Нормальный план — переходи к 3.3.

3.3. Показать план пользователю и ждать «ok»

Выведи нумерованный список шагов с критериями (в том виде, в котором их вернул planner). Явно спроси:

Принимаем план?

• y — выполнять
• n — отменить
• правки — опиши что изменить, planner переработает

Без подтверждения не двигаться. На «правки» — снова вызови planner в том же cycle с фидбеком пользователя в prompt'е, потом снова покажи план.

3.4. Step loop (последовательно)

Для каждого шага в порядке нумерации:

attempts = 0

Цикл попыток:

1. Вызов worker через Agent (Task) tool, subagent_type=worker. Prompt включает:
   • Блок шага (ШАГ N, Файлы, Действия, Критерии приёмки, Зависимости) как есть из плана.
   • previous_steps_context — для каждого шага из поля Зависимости подставь запись из worker_summaries. Если Зависимости: нет — поле опустить.
   • judger_feedback — только если attempts > 0, текст последнего вердикта STEP.
2. После worker — сохрани в worker_summaries[N] строку вида: тронутые файлы: <список>, summary: <первое предложение из "Что сделано">.
3. Если worker вернул BLOCKED: <причина> — escalation step-level (см. ниже).
4. Вызов judger через Agent (Task) tool, subagent_type=judger. Prompt начинается с [STEP] + блок шага + WORKER REPORT.
5. Разбор статуса:
   • Статус: PASS → следующий шаг.
   • Статус: FAIL и attempts < MAX_ATTEMPTS - 1 → attempts++, вернуться к шагу 1 с judger_feedback.
   • Статус: FAIL и attempts == MAX_ATTEMPTS - 1 (то есть это была 3-я попытка) → escalation step-level.

Escalation step-level

Останови step-loop. Выведи пользователю:

• Какой шаг провалился (номер, название).
• Последний WORKER REPORT (тронутые файлы, что сделано).
• Последний JUDGER VERDICT [STEP] (провалы, совет worker).

Спроси через AskUserQuestion:

• Принять как есть — записать в worker_summaries как «принято с провалами», перейти к следующему шагу.
• Переформулировать шаг — пользователь даёт новую формулировку, attempts = 0, продолжить step-loop с этим шагом.
• Отменить /pwj — выйти полностью. Файлы не откатывать — пользователь сам через git.

3.5. После всех шагов — cycle-judger

Вызов judger через Agent (Task) tool, subagent_type=judger. Prompt начинается с [CYCLE] + исходная задача + полный план + все WORKER REPORTS подряд + агрегированный список тронутых файлов.

Разбор статуса:

• Статус: GOAL_ACHIEVED → выход из cycle-loop, перейти к шагу 4 (/preflight).
• Статус: NEEDS_ANOTHER_CYCLE и cycle < MAX_CYCLES →
  • cycle++
  • cycle_diagnosis = <"Cycle diagnosis для planner" из вердикта>
  • Файлы не откатывать — следующий cycle работает поверх состояния.
  • Вернуться к 3.1.
• Статус: NEEDS_ANOTHER_CYCLE и cycle == MAX_CYCLES → escalation cycle-level.
• Статус: UNRECOVERABLE → escalation cycle-level сразу.

Escalation cycle-level

Выведи пользователю:

• Исходную задачу.
• Последний CYCLE JUDGER VERDICT (что достигнуто, пробелы, регрессии, диагноз).
• Сколько cycles прошло.

Спроси через AskUserQuestion:

• Принять как есть — перейти к /preflight.
• Ещё cycle вручную — пользователь даёт уточнённую формулировку, cycle = 1, начать заново (но файлы не откатывать).
• Отменить /pwj — выйти. Файлы не откатывать.

4. /preflight автоматически

После выхода из cycle-loop (через GOAL_ACHIEVED или «Принять как есть» из escalation) — автоматически вызови слэш-команду /preflight (.claude/commands/preflight.md). Не показывай рекомендацию, не спрашивай — сразу гнать.

5. Финальный отчёт

После /preflight выведи короткий итог:

PWJ FINAL REPORT
Cycles выполнено: <N>
Тронутые файлы (агрегировано): <список>
Step-эскалации: <если были — какие шаги и решение пользователя; иначе "—">
Cycle-эскалации: <если были — иначе "—">
/preflight: <результат: ok / упал и где>
Дальше: <если /preflight упал — что чинить; если ok — "готово к git add/commit на усмотрение пользователя">

Замечания

• Сабагенты вызываются только через Agent (Task) tool. Не пытаться «исполнять» их инлайн в чате.
• Не дёргать /preflight внутри cycle-loop — step-judger делает локальные проверки, cycle-judger делает goal-check, /preflight — финальный синтаксис+тесты.
• Не коммитить — git add/git commit/git push — явное действие пользователя. /pwj никогда не делает их.
• Если planner упал/таймаут/вернул мусор — деградировать в обычный режим (выполни задачу сам без агентов), явно сообщить пользователю: «planner недоступен, делаю руками».
• Если worker или judger упали — повтори вызов один раз. Если снова — escalation step-level с пометкой «технический сбой».
• cycle_diagnosis передавать planner'у дословно, не пересказывать — это формализованный input от judger к planner.