Back to Details

plan-arbiter

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan Arbiter

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.
  1. 收集源方案。
  2. 将每个方案标准化为可对比的要点。
  3. 结合实际代码库或任务上下文，对方案进行交叉评审。
  4. 选定最优方案、合并出更优的混合方案，或退回方案要求修订。
  5. 生成一份包含验证节点和被否决替代方案的执行交接文档。
除非用户明确要求在决策后进行实施，否则规划阶段仅为只读操作。

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.
接受以粘贴文本、本地文件、会话ID、记录路径、PR、评论、可视化方案链接或聊天历史形式提供的方案。尽可能获取原始工件，以便查看可能在最终摘要中遗漏的提示变更和假设。
若方案仍在撰写中且用户要求等待，则持续监控直至完成或受阻。若无法获取完整源方案，则基于现有方案文本继续，并标记缺失源为风险点。

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.
针对每个方案，提取以下内容：
  • 目标与范围。
  • 关键假设与未解决问题。
  • 提议的文件、模块、API、数据结构、UI状态或工作流。
  • 实施顺序。
  • 验证策略。
  • 回滚或迁移相关顾虑。
  • 成本、复杂度及预期执行者适配性。
不推崇冗长表述。优先选择具体、基于真实代码且坦诚说明权衡取舍的方案。

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.
以其他能力型Agent的视角评审每个方案：
  • 检查方案是否满足用户的实际需求。
  • 若相关且可获取，对照代码库、文档、测试、截图或外部系统验证方案中的主张。
  • 识别隐藏依赖、缺失测试、风险排序、模糊步骤、不必要范围及难以撤销的决策。
  • 发现互补优势：一个方案可能拥有更优架构，而另一个方案的迁移或验证路径更出色。
  • 将方案质量与执行者偏好区分开。即使其他模型提出了最佳评审意见，成本更低/速度更快的执行者仍可能是实施的正确选择。
当方案规模较大、代码库范围较广，或决策需分别从技术和产品层面进行评审时，使用子Agent进行独立评审。

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.
选择以下三种结果之一：
  • 采纳： 基本按原样选定一个方案。
  • 混合： 整合各方案的特定部分，形成更强大的执行方案。
  • 先修订： 要求重新规划，因为两个方案均遗漏关键约束或依赖未解决的决策。
遵循以下优先级进行平局裁决：
  1. 正确性及与用户需求的契合度。
  2. 基于真实文件、API、测试、数据和UI行为的落地性。
  3. 简单的初始实施，且不阻碍未来的预期发展。
  4. 更完善的验证与回滚机制。
  5. 质量达标后，执行所需的令牌/时间成本更低。

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.
返回一份简洁的决策备忘录：
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.
若用户已要求实施且选定路径清晰，则在简要汇报决策后直接按选定方案执行。否则在交接阶段停止，等待用户批准。