paseo-committee

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Committee Skill

Committee技能

You are forming a committee to step back from the current problem and get fresh perspective.

User's additional context: $ARGUMENTS

你将组建一个委员会，跳出当前问题的局限，获取全新视角。

用户补充上下文： $ARGUMENTS

Prerequisites

前置条件

Load the Paseo skill first — it contains the CLI reference for all agent commands and waiting guidelines.

请先加载Paseo skill——它包含所有Agent命令的CLI参考文档和等待准则。

What Is a Committee

什么是委员会

Two agents — Opus 4.6 (

--thinking on

) and GPT 5.4 (

--thinking medium

) — launched in parallel to plan a solution. Fresh context, no implementation baggage, proper root cause analysis.

They stay alive after planning for Phase 3 review — they hold only the plan, so they catch implementation drift.

The purpose is to step back, not to double down. The committee may propose a completely different approach.

由两名Agent并行启动以规划解决方案：Opus 4.6（

--thinking on

）和GPT 5.4（

--thinking medium

）。它们拥有全新的上下文，没有历史实现包袱，能开展专业的根本原因分析。

规划完成后，这些Agent会保持活跃以参与第三阶段的评审——它们仅保留计划内容，因此能及时发现实现偏差。

**核心目标是跳出局限，而非钻牛角尖。**委员会可能会提出完全不同的解决方案。

Your Role

你的角色

You drive the full lifecycle: plan → implement → review. You are a middleman between the user and the committee. Do not yield back to the user until the cycle is complete. If the user needs to weigh in on a divergence, ask them — but don't stop the process.

你需要主导完整的生命周期：规划→实施→评审。你是用户与委员会之间的中间人，在整个周期完成前不要将控制权交还给用户。若委员会的方案与预期存在分歧需要用户决策，可询问用户，但不要中断流程。

No Anxiety

无需焦虑

Once you call
paseo wait
, trust the wait. Do not poll logs, read output early, send hurry-up messages, interrupt deep analysis, or give up because it's taking long.

GPT 5.4 can reason for 15–30 minutes. Opus does extended thinking. Long waits mean the agent found something worth thinking about. Let it finish.

If the CLI has a bug, the user will tell you.

**一旦调用

paseo wait

，请信任等待过程。**不要轮询日志、提前查看输出、发送催促消息、打断深度分析，也不要因为耗时过长就放弃。

GPT 5.4的推理时间可达15–30分钟，Opus则会进行更深入的思考。等待时间长意味着Agent发现了值得深入分析的内容，请让它完成思考。

如果CLI出现故障，用户会告知你。

No-Edits Suffix

禁止编辑后缀

Every prompt to a committee member — initial, follow-up, or review — must end with this suffix. They will start editing code if you don't.

NO_EDITS="This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code."

All example prompts below include

$NO_EDITS

— always expand it.

发送给委员会成员的所有提示——初始提示、跟进提示或评审提示——必须以以下后缀结尾。否则它们会开始编辑代码。

NO_EDITS="This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code."

以下所有示例提示均包含

$NO_EDITS

——请务必展开该变量。

Phase 1: Get a Plan

第一阶段：制定计划

Write the prompt

编写提示

Describe the overall problem, not just the immediate symptom:

High-level goal and acceptance criteria
Constraints
Symptoms (if a bug)
What you've tried and why it failed
Explicitly ask for root cause analysis

bash

prompt="We're trying to [high-level goal]. Constraints: [X, Y, Z]. Acceptance criteria: [A, B, C].

We've been stuck on this. Here's what we've tried and why it didn't work:
- [approach 1] — failed because [reason]
- [approach 2] — partially worked but [issue]

Step back from these attempts. Do root cause analysis — the fix might not be for [immediate symptom] at all, it might be structural.

Use the think-harder approach: state your assumptions, ask why at least 3 levels deep for each, and check whether you're patching a symptom or removing the problem. What's the right approach?

$NO_EDITS"

描述整体问题，而非仅当前症状：

高层目标与验收标准
约束条件
症状（如果是Bug）
已尝试的方案及失败原因
明确要求进行根本原因分析

bash

prompt="我们正尝试[高层目标]。约束条件：[X, Y, Z]。验收标准：[A, B, C]。

我们在此问题上陷入了瓶颈。以下是已尝试的方案及失败原因：
- [方案1]——失败原因：[具体原因]
- [方案2]——部分有效，但存在[问题]

请跳出这些尝试的局限，进行根本原因分析——修复方案可能根本不是针对[当前症状]，而是结构性的问题。

采用深度思考法：列出你的假设，对每个假设至少追问3层“为什么”，检查我们是在治标还是治本。正确的解决方案是什么？

$NO_EDITS"

Launch both members

启动两名委员会成员

Same prompt to both,

[Committee]

prefix for identification:

bash

opus_id=$(paseo run -d --mode bypass --model opus --thinking on --name "[Committee] Task description" "$prompt" -q)
gpt_id=$(paseo run -d --mode full-access --provider codex --model gpt-5.4 --thinking medium --name "[Committee] Task description" "$prompt" -q)

向两者发送相同的提示，使用

[Committee]

前缀以作标识：

bash

opus_id=$(paseo run -d --mode bypass --model opus --thinking on --name "[Committee] Task description" "$prompt" -q)
gpt_id=$(paseo run -d --mode full-access --provider codex --model gpt-5.4 --thinking medium --name "[Committee] Task description" "$prompt" -q)

Wait for both

等待两者完成

Wait for both agents — not just the first one that finishes.

bash

paseo wait "$opus_id"
paseo wait "$gpt_id"

必须等待两名Agent完成，而非仅第一个完成的。

bash

paseo wait "$opus_id"
paseo wait "$gpt_id"

Read and challenge

阅读并质疑

bash

paseo logs "$opus_id"
paseo logs "$gpt_id"

Do not accept output at face value. Use the think-harder framework to challenge their output. Before synthesizing:

Ask "why" 2–3 levels deep. "Fix X because Y is broken" — why is Y broken? Is Y a root cause or a consequence?
Challenge assumptions. If the plan assumes something about the code, make the agent verify it.
Symptom vs cause. "Are we fixing the consequence or the cause?"
Probe alternatives. "What did you consider and reject?"

bash

paseo send "$opus_id" "You said [X]. Why does [underlying thing] happen in the first place? Are we patching a symptom? $NO_EDITS"
paseo wait "$opus_id"
paseo logs "$opus_id"

Keep pushing until the plan addresses the root cause.

bash

paseo logs "$opus_id"
paseo logs "$gpt_id"

不要直接接受输出内容。使用深度思考框架来质疑它们的输出。在综合方案前：

**追问2–3层“为什么”。**比如“修复X是因为Y出了问题”——那Y为什么会出问题？Y是根本原因还是结果？
**质疑假设。**如果计划中对代码有假设，请让Agent验证该假设。
区分症状与原因。“我们是在修复结果还是原因？”
探讨替代方案。“你考虑过哪些方案并否决了？”

bash

paseo send "$opus_id" "你提到了[X]。[底层问题]最初是如何产生的？我们是不是在治标？$NO_EDITS"
paseo wait "$opus_id"
paseo logs "$opus_id"

持续追问，直到计划能解决根本原因。

Synthesize and confirm

综合并确认

Convergence → merge into unified plan.
Significant divergence → involve the user.

Send the merged plan back for confirmation. Multi-turn if needed — keep going until consensus.

bash

paseo send "$opus_id" "Merged plan: [plan]. Concerns? $NO_EDITS"
paseo send "$gpt_id" "Merged plan: [plan]. Concerns? $NO_EDITS"

若意见一致→合并为统一计划。
若存在重大分歧→请用户参与决策。

将合并后的计划发回给委员会确认。必要时可进行多轮沟通——直到达成共识。

bash

paseo send "$opus_id" "合并后的计划：[计划内容]。有疑问吗？$NO_EDITS"
paseo send "$gpt_id" "合并后的计划：[计划内容]。有疑问吗？$NO_EDITS"

Phase 2: Implement

第二阶段：实施

Implement the plan yourself — unless the user said "delegate", in which case launch an implementer:

bash

impl_id=$(paseo run -d --mode full-access --provider codex --name "[Impl] Task description" "Implement the following plan end-to-end. [plan]" -q)
paseo wait "$impl_id"

Committee agents stay clean — not involved in implementation.

自行实施计划——除非用户明确要求**“委托”**，否则请启动一个实施Agent：

bash

impl_id=$(paseo run -d --mode full-access --provider codex --name "[Impl] Task description" "端到端实施以下计划。[计划内容]" -q)
paseo wait "$impl_id"

委员会Agent需保持独立——不参与实施过程。

Phase 3: Review

第三阶段：评审

Send the committee the changes for review. They anchor against the plan and catch drift.

bash

review_prompt="Implementation is done. Review changes against the plan. Flag drift or missing pieces. $NO_EDITS"

paseo send "$opus_id" "$review_prompt"
paseo send "$gpt_id" "$review_prompt"

paseo wait "$opus_id"
paseo wait "$gpt_id"

paseo logs "$opus_id"
paseo logs "$gpt_id"

将实施变更发送给委员会进行评审。它们会对照计划，及时发现偏差。

bash

review_prompt="实施已完成。请对照计划评审变更内容，标记偏差或遗漏部分。$NO_EDITS"

paseo send "$opus_id" "$review_prompt"
paseo send "$gpt_id" "$review_prompt"

paseo wait "$opus_id"
paseo wait "$gpt_id"

paseo logs "$opus_id"
paseo logs "$gpt_id"

Iterate

迭代

Send committee feedback to the implementer (or apply yourself). Repeat Phase 2 → 3 until the committee confirms the implementation matches the plan.

After ~10 iterations without convergence, start a fresh committee with full context of what was tried — the current committee's context may have drifted too far.

将委员会的反馈发送给实施Agent（或自行调整）。重复第二阶段→第三阶段，直到委员会确认实施内容与计划一致。

若经过约10次迭代仍未达成一致，请结合已尝试的所有内容启动新的委员会——当前委员会的上下文可能已经偏离过多。