Дом

Skill

Производительность и рабочий процесс

plan-arbiter

BuilderIO/skills

Сравнивайте, проводите перекрестную проверку и объединяйте конкурирующие планы от нескольких агентов в единое исполняемое направление с четким распределением обязанностей.

...Расширить все

Обновлено время 6 сентября 2026 г.

# planning # handoff # decision making # cross review # execution plan

«Арбитр планов»

Превратите конкурирующие планы в единое реализуемое направление. Сохраните лучшие идеи, отвергните слабые предположения и создайте четкий план действий вместо беспорядочной смеси.

Рабочий процесс

Соберите исходные планы.
Приведите каждый план к сопоставимым утверждениям.
Проведите перекрестную проверку планов друг относительно друга, а также по сравнению с реальной кодовой базой или контекстом задачи .
Выберите победителя, сформируйте более удачную гибридную версию или отправьте планы на доработку.
Создайте единую передачу на выполнение с контрольными точками проверки и отклоненными альтернативами.

Планирование доступно только для чтения, если пользователь явно не попросит вас приступить к реализации после принятия решения.

Сбор исходных планов

Принимайте планы в виде вставленного текста, локальных файлов, идентификаторов сеансов, путей к стенограммам, PR, комментариев, ссылок на визуальные планы или истории чата. Разобраться с исходными артефактами, когда это возможно, чтобы вы могли увидеть оперативные изменения и допущения, которые могут отсутствовать в окончательном резюме.

Если план ещё находится в стадии написания и пользователь попросил вас подождать, отслеживайте его до тех пор, пока он не будет завершён или заблокирован. Если план не удаётся определить, продолжайте работу с доступным текстом плана и отметьте отсутствующий исходный материал как риск.

Нормализация

Для каждого плана извлеките:

Цель и объем.
Ключевые допущения и нерешенные вопросы.
Предлагаемые файлы, модули, API, форматы данных, состояния пользовательского интерфейса или рабочие процессы.
Последовательность реализации.
Стратегию валидации.
Проблемы, связанные с откатом или миграцией.
Стоимость, сложность и ожидаемая пригодность исполнителя.

Не поощряйте многословность. Отдавайте предпочтение планам, которые являются конкретными, основанными на реальном коде и честно отражают компромиссы.

Взаимная экспертиза

Проверяйте каждый план так, как будто его написал другой компетентный специалист:

Проверьте, соответствует ли он фактическому запросу пользователя.
Проверяйте заявления, сверяя их с репозиторием, документацией, тестами, скриншотами или внешними системами, если они имеют отношение к делу и доступны.
Выявляйте скрытые зависимости, отсутствующие тесты, рискованную последовательность действий, нечеткие шаги, ненужный объем работ и решения, которые трудно отменить.
Обращайте внимание на взаимодополняющие преимущества: один план может иметь лучшую архитектуру, а другой — более эффективный путь миграции или валидации.
Не смешивайте качество плана с личными предпочтениями исполнителя. Более дешёвый/быстрый исполнитель может оказаться правильным выбором для реализации, даже если другая модель получила лучшие отзывы.

Используйте субагентов для независимой экспертизы, если планы обширны, кодовая база широка или если для принятия решения целесообразно провести отдельные технические и продуктовые проверки.

Примите решение

Выберите один из трёх вариантов:

Принять: выбрать один план практически в том виде, в каком он написан.
Гибридный вариант: объединить отдельные части в более эффективный план выполнения.
«Сначала пересмотреть»: запросите повторный этап планирования, поскольку оба плана не учитывают ключевое ограничение или зависят от нерешенного вопроса.

Используйте следующий порядок при равенстве голосов:

Правильность и соответствие запросу пользователя.
Обоснованность реальными файлами, API, тестами, данными и поведением пользовательского интерфейса.
Более простая первоначальная реализация, которая не препятствует запланированным дальнейшим шагам.
Более качественная проверка и механизм отката.
Меньшие затраты токенов/времени на выполнение, если качество является приемлемым.

Передача

Верните краткую записку с решением:

Decision
- Adopt Plan A / Hybrid / Revise first.

Why
- The deciding evidence and tradeoffs.

Execution Plan
- Ordered steps with files or surfaces to touch.

Borrowed From Other Plans
- Useful pieces kept from non-winning plans.

Rejected
- Ideas intentionally not taking, with reasons.

Verification
- Tests, browser checks, screenshots, CI, review, or deploy checks needed.

Executor Recommendation
- Which agent/model should implement and why.

Если пользователь уже запросил выполнение и выбранный путь ясен, приступить к реализации выбранного плана после краткого сообщения о решении. В противном случае остановиться на этапе передачи и запросить одобрение.

Посмотреть на GitHub

---
name: plan-arbiter
description: Compare, cross-review, and merge competing plans from multiple agents into one executable direction with a clear handoff.
---

# Plan Arbiter

Turn competing plans into one executable direction. Preserve the best ideas,
reject weak assumptions, and produce a clear handoff instead of a blended mush.

## Workflow

1. Collect the source plans.
2. Normalize each plan into comparable claims.
3. Cross-review the plans against each other and the real codebase or task
   context.
4. Choose a winner, merge a better hybrid, or send the plans back for revision.
5. Produce one execution handoff with verification gates and rejected
   alternatives.

Planning is read-only unless the user explicitly asks you to implement after the
decision.

## Collect Source Plans

Accept plans as pasted text, local files, session IDs, transcript paths, PRs,
comments, visual-plan links, or chat history. Resolve the original artifacts
when possible so you can see prompt changes and assumptions that may be missing
from a final summary.

If a plan is still being written and the user asked you to wait, monitor it
until it is done or blocked. If a plan cannot be resolved, continue with the
available plan text and mark the missing source as a risk.

## Normalize

For each plan, extract:

- Objective and scope.
- Key assumptions and unresolved questions.
- Proposed files, modules, APIs, data shapes, UI states, or workflows.
- Implementation sequence.
- Validation strategy.
- Rollback or migration concerns.
- Cost, complexity, and expected executor fit.

Do not reward verbosity. Prefer plans that are concrete, grounded in real code,
and honest about tradeoffs.

## Cross-Review

Review each plan as if another capable agent wrote it:

- Check whether it satisfies the user's actual request.
- Verify claims against the repo, docs, tests, screenshots, or external systems
  when those are relevant and available.
- Identify hidden dependencies, missing tests, risky sequencing, vague steps,
  unnecessary scope, and hard-to-reverse decisions.
- Notice complementary strengths: one plan may have the better architecture
  while another has the better migration or validation path.
- Separate plan quality from executor preference. A cheaper/faster executor can
  be the right choice for implementation even when another model produced the
  best critique.

Use subagents for independent review when the plans are large, the codebase is
wide, or the decision would benefit from separate technical and product passes.

## Decide

Choose one of three outcomes:

- **Adopt:** pick one plan mostly as written.
- **Hybrid:** combine specific pieces into a stronger execution plan.
- **Revise first:** request another planning pass because both plans miss a
  key constraint or depend on an unresolved decision.

Use this tie-break order:

1. Correctness and fit to the user's request.
2. Grounding in real files, APIs, tests, data, and UI behavior.
3. Simpler first implementation that does not block the intended future.
4. Better validation and rollback story.
5. Lower token/time cost for execution once quality is acceptable.

## Handoff

Return a compact decision memo:

```md
Decision
- Adopt Plan A / Hybrid / Revise first.

Why
- The deciding evidence and tradeoffs.

Execution Plan
- Ordered steps with files or surfaces to touch.

Borrowed From Other Plans
- Useful pieces kept from non-winning plans.

Rejected
- Ideas intentionally not taking, with reasons.

Verification
- Tests, browser checks, screenshots, CI, review, or deploy checks needed.

Executor Recommendation
- Which agent/model should implement and why.
```

When the user already asked for execution and the chosen path is clear, proceed
with the selected plan after reporting the decision briefly. Otherwise stop at
the handoff and ask for approval.