Hogar

Skill

Productividad y flujo de trabajo

plan-arbiter

BuilderIO/skills

Comparar, contrastar y fusionar los planes de varios agentes en una única línea de actuación viable con un traspaso de responsabilidades claro.

...Expandir todo

Tiempo actualizado 6 de septiembre de 2026

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

Plan Arbiter

Convierte los planes contrapuestos en una única línea de actuación viable. Conserva las mejores ideas, descarta las hipótesis poco sólidas y elabora un traspaso claro, en lugar de un batiburrillo confuso.

Flujo de trabajo

Recopila los planes originales.
Normaliza cada plan en afirmaciones comparables.
Revisa los planes entre sí y compáralos con el código real o el contexto de la tarea .
Elige un plan ganador, fusiona una versión híbrida mejorada o devuelve los planes para su revisión.
Generar un traspaso de ejecución con controles de verificación y alternativas rechazadas .

La planificación es de solo lectura, a menos que el usuario te pida explícitamente que la implementes tras la decisión.

Recopila planes de origen

Acepta los planes como texto pegado, archivos locales, ID de sesión, rutas de transcripciones, PR, comentarios, enlaces a planes visuales o historial de chat. Resuelve los artefactos originales siempre que sea posible para que puedas ver los cambios en el indicador y las suposiciones que puedan faltar en un resumen final.

Si un plan aún se está redactando y el usuario te ha pedido que esperes, supervisa su estado hasta que esté terminado o se bloquee. Si un plan no se puede resolver, continúa con el texto del plan disponible y marca la fuente que falta como un riesgo.

Normalizar

Para cada plan, extrae:

Objetivo y alcance.
Supuestos clave y cuestiones sin resolver.
Archivos, módulos, API, estructuras de datos, estados de la interfaz de usuario o flujos de trabajo propuestos.
Secuencia de implementación.
Estrategia de validación.
Cuestiones relacionadas con la reversión o la migración.
Coste, complejidad y adecuación prevista del ejecutor.

No se valorará la verbosidad. Se preferirán los planes que sean concretos, basados en código real y sinceros respecto a las compensaciones.

Revisión cruzada

Revisa cada plan como si lo hubiera escrito otro agente competente:

Comprueba si satisface la solicitud real del usuario.
Verifica las afirmaciones contrastándolas con el repositorio, la documentación, las pruebas, las capturas de pantalla o los sistemas externos cuando sean relevantes y estén disponibles.
Identifica dependencias ocultas, pruebas que faltan, secuencias arriesgadas, pasos vagos, alcance innecesario y decisiones difíciles de revertir.
Ten en cuenta los puntos fuertes complementarios: un plan puede tener la mejor arquitectura, mientras que otro ofrece la mejor ruta de migración o validación.
Separa la calidad del plan de las preferencias del ejecutor. Un ejecutor más barato o rápido puede ser la elección adecuada para la implementación, incluso cuando otro modelo haya generado la mejor crítica.

Utiliza subagentes para una revisión independiente cuando los planes sean extensos, el código fuente sea amplio o la decisión se beneficie de revisiones técnicas y de producto por separado.

Decide

Elige uno de estos tres resultados:

Adoptar: elegir un plan tal y como está redactado en su mayor parte.
Híbrido: combinar partes específicas para crear un plan de ejecución más sólido.
Revisar primero: solicita otra ronda de planificación porque ambos planes pasan por alto una restricción clave o dependen de una decisión pendiente.

Utiliza este orden de desempate:

Exactitud y adecuación a la solicitud del usuario.
Basarse en archivos reales, API, pruebas, datos y comportamiento de la interfaz de usuario.
Una primera implementación más sencilla que no bloquee el futuro previsto.
Mejor proceso de validación y reversión.
Menor coste en tokens o tiempo de ejecución una vez que la calidad sea aceptable.

Traspaso

Devuelve una nota de decisión concisa:

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.

Cuando el usuario ya haya solicitado la ejecución y la ruta elegida esté clara, se procede con el plan seleccionado tras informar brevemente de la decisión. De lo contrario, se detiene en el traspaso y se solicita aprobación.

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