Heim

Skill

Produktivität und Workflow

plan-arbiter

BuilderIO/skills

Vergleichen, gegenprüfen und zusammenführen Sie konkurrierende Pläne verschiedener Beteiligter zu einer umsetzbaren Vorgehensweise mit einer klaren Übergabe.

...Alle erweitern

Zeit aktualisiert 6. September 2026

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

Plan-Arbiter

Fassen Sie konkurrierende Pläne zu einer umsetzbaren Strategie zusammen. Behalten Sie die besten Ideen bei, verwerfen Sie schwache Annahmen und erstellen Sie eine klare Übergabe statt eines unübersichtlichen Durcheinanders.

Ablauf

Sammeln Sie die Ausgangspläne.
Normalisieren Sie jeden Plan in vergleichbare Aussagen.
Prüfen Sie die Pläne gegenseitig sowie im Vergleich zur tatsächlichen Codebasis oder dem Aufgabenkontext gegen.
Wählen Sie einen Gewinner aus, erstellen Sie eine optimierte Mischform oder senden Sie die Pläne zur Überarbeitung zurück.
Erstellen Sie eine einzige Ausführungsübergabe mit Verifizierungsschritten und abgelehnten Alternativen.

Die Planung ist schreibgeschützt, es sei denn, der Benutzer fordert Sie nach der Entscheidung ausdrücklich zur Umsetzung auf.

Quellpläne sammeln

Akzeptiere Pläne als eingefügten Text, lokale Dateien, Sitzungs-IDs, Transkriptpfade, PRs, Kommentare, Links zu visuellen Plänen oder Chat-Verlauf. Kläre die ursprünglichen Artefakte nach Möglichkeit auf, damit du sofort Änderungen und Annahmen erkennen kannst, die möglicherweise in einer abschließenden Zusammenfassung fehlen.

Wenn ein Plan noch in Arbeit ist und der Benutzer Sie gebeten hat zu warten, überwachen Sie ihn, bis er fertiggestellt oder blockiert ist. Wenn ein Plan nicht aufgelöst werden kann, fahren Sie mit dem verfügbaren Plantext fort und kennzeichnen Sie die fehlende Quelle als Risiko.

Normalisieren

Extrahieren Sie für jeden Plan:

Ziel und Umfang.
Wichtige Annahmen und offene Fragen.
Vorgeschlagene Dateien, Module, APIs, Datenformate, UI-Zustände oder Workflows.
Implementierungsreihenfolge.
Validierungsstrategie.
Bedenken hinsichtlich Rollback oder Migration.
Kosten, Komplexität und Eignung des erwarteten Ausführers.

Ausführlichkeit wird nicht belohnt. Bevorzugt werden Pläne, die konkret sind, auf echtem Code basieren und Kompromisse ehrlich darstellen.

Gegenseitige Überprüfung

Überprüfen Sie jeden Plan so, als hätte ihn ein anderer kompetenter Mitarbeiter verfasst:

Prüfen Sie, ob er der tatsächlichen Anforderung des Nutzers entspricht.
Überprüfen Sie die Angaben anhand des Repos, der Dokumentation, der Tests, der Screenshots oder externer Systeme, sofern diese relevant und verfügbar sind.
Identifizieren Sie versteckte Abhängigkeiten, fehlende Tests, riskante Abläufe, vage Schritte, unnötigen Umfang und schwer rückgängig zu machende Entscheidungen.
Beachten Sie sich ergänzende Stärken: Ein Plan hat vielleicht die bessere Architektur, während ein anderer den besseren Migrations- oder Validierungspfad aufweist.
Trenne die Qualität des Plans von den Präferenzen des Ausführenden. Ein kostengünstigerer/schnellerer Ausführender kann die richtige Wahl für die Umsetzung sein, selbst wenn ein anderes Modell die beste Bewertung erhalten hat.

Setzen Sie Unteragenten für eine unabhängige Überprüfung ein, wenn die Pläne umfangreich sind, die Codebasis breit gefächert ist oder die Entscheidung von getrennten technischen und produktbezogenen Durchläufen profitieren würde.

Entscheiden Sie sich

Wählen Sie eines von drei Ergebnissen:

Übernehmen: Wählen Sie einen Plan, der weitgehend unverändert bleibt.
Hybrid: Kombinieren Sie bestimmte Teile zu einem stärkeren Ausführungsplan.
Zuerst überarbeiten: Fordern Sie einen weiteren Planungsdurchlauf an, da beide Pläne eine wesentliche Einschränkung außer Acht lassen oder von einer noch nicht getroffenen Entscheidung abhängen.

Verwenden Sie folgende Reihenfolge bei Gleichstand:

Richtigkeit und Übereinstimmung mit der Anfrage des Nutzers.
Verankerung in realen Dateien, APIs, Tests, Daten und dem Verhalten der Benutzeroberfläche.
Einfachere erste Implementierung, die die beabsichtigte zukünftige Entwicklung nicht blockiert.
Bessere Validierung und Rollback-Strategie.
Geringerer Token-/Zeitaufwand für die Ausführung, sobald die Qualität akzeptabel ist.

Übergabe

Geben Sie eine kurze Entscheidungsnotiz zurück:

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.

Wenn der Benutzer bereits um die Ausführung gebeten hat und der gewählte Weg klar ist, fahren Sie mit dem ausgewählten Plan fort, nachdem Sie die Entscheidung kurz mitgeteilt haben. Andernfalls halten Sie an der Übergabe an und bitten um Zustimmung.

Auf GitHub ansehen

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