Lar

Skill

Produtividade e fluxo de trabalho

plan-arbiter

BuilderIO/skills

Comparar, analisar de forma cruzada e integrar planos concorrentes de vários agentes em uma única orientação executável, com uma transferência de responsabilidades clara.

...Expandir tudo

Tempo atualizado 6 de Setembro de 2026

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

Árbitro de Planos

Transforme planos concorrentes em uma única direção executável. Preserve as melhores ideias, rejeite premissas fracas e produza uma transição clara, em vez de uma mistura confusa.

Fluxo de trabalho

Reúna os planos originais.
Normalize cada plano em afirmações comparáveis.
Faça uma análise cruzada dos planos entre si e em relação à base de código real ou ao contexto da tarefa .
Escolha um vencedor, crie uma versão híbrida aprimorada ou devolva os planos para revisão.
Produza uma transferência de execução com etapas de verificação e alternativas rejeitadas .

O planejamento é somente para leitura, a menos que o usuário peça explicitamente para você implementar após a decisão.

Colete planos de origem

Aceite planos como texto colado, arquivos locais, IDs de sessão, caminhos de transcrições, PRs, comentários, links para planos visuais ou histórico de bate-papo. Resolva os artefatos originais sempre que possível para que você possa ver alterações imediatas e suposições que possam estar faltando no resumo final.

Se um plano ainda estiver sendo elaborado e o usuário tiver solicitado que você aguarde, monitore-o até que seja concluído ou bloqueado. Se um plano não puder ser resolvido, continue com o texto do plano disponível e marque a fonte ausente como um risco.

Normalize

Para cada plano, extraia:

Objetivo e escopo.
Suposições-chave e questões não resolvidas.
Arquivos, módulos, APIs, formatos de dados, estados da interface do usuário ou fluxos de trabalho propostos.
Sequência de implementação.
Estratégia de validação.
Preocupações com reversão ou migração.
Custo, complexidade e adequação esperada do executor.

Não valorize a prolixidade. Dê preferência a planos que sejam concretos, baseados em código real e sinceros quanto às compensações.

Revisão cruzada

Analise cada plano como se tivesse sido escrito por outro profissional competente:

Verifique se ele atende à solicitação real do usuário.
Verifique as afirmações em relação ao repositório, à documentação, aos testes, às capturas de tela ou a sistemas externos, quando forem relevantes e estiverem disponíveis.
Identifique dependências ocultas, testes ausentes, sequências de risco, etapas vagas, escopo desnecessário e decisões difíceis de reverter.
Observe os pontos fortes complementares: um plano pode ter a melhor arquitetura, enquanto outro apresenta o melhor caminho de migração ou validação.
Separe a qualidade do plano da preferência pelo executor. Um executor mais barato/rápido pode ser a escolha certa para a implementação, mesmo quando outro modelo produziu a melhor avaliação.

Utilize subagentes para revisão independente quando os planos forem extensos, a base de código for ampla ou a decisão se beneficiar de análises técnicas e de produto separadas.

Decida

Escolha um dos três resultados:

Adotar: escolha um plano praticamente como está escrito.
Híbrido: combine partes específicas em um plano de execução mais robusto.
Revisar primeiro: solicite outra rodada de planejamento, pois ambos os planos omitem uma restrição fundamental ou dependem de uma decisão ainda não resolvida.

Use esta ordem de desempate:

Precisão e adequação à solicitação do usuário.
Base em arquivos reais, APIs, testes, dados e comportamento da interface do usuário.
Primeira implementação mais simples que não bloqueie o futuro pretendido.
Melhor processo de validação e reversão.
Menor custo de tokens/tempo de execução, uma vez que a qualidade seja aceitável.

Transferência

Retorne um memorando de decisão conciso:

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.

Quando o usuário já solicitou a execução e o caminho escolhido estiver claro, prossiga com o plano selecionado após relatar brevemente a decisão. Caso contrário, pare na transferência e solicite aprovação.

Ver no 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.