unstuck

/ouroboros:unstuck

借助横向思维角色打破停滞，或为艰难抉择提供建议。Solo 会运行一个角色；debate 会并行运行多个角色并综合结果。

用法

ooo lateral                       # debate: all 5 lateral personas
ooo lateral <persona>             # solo: one persona
ooo lateral debate <p1> <p2> ...  # debate with explicit members
ooo lateral @all                  # debate preset (the only preset)

角色（横向思维池）

仅提供无状态的重新审视视角；有状态角色（evaluator、qa-judge、ontologist、socratic-interviewer）各自拥有独立的技能。

角色	视角	适用情况
hacker	先让它跑起来，再追求优雅	想得太多，阻碍了进展
researcher	我们缺少哪些信息？	问题尚不明确
simplifier	缩小范围，回归 MVP	复杂性令人难以招架
architect	完全重新构思方案	当前设计有问题
contrarian	我们是不是在解决错误的问题？	需要质疑假设

除了直接调用 ooo lateral，你也可以从其他技能链接到此技能（例如在 ooo interview 中作为 socratic-interviewer），以便在当前问题需要多角度审议时使用；之后总结各种选项，返回父级流程，并由用户决定。

说明

步骤 1：解析参数并确定模式

输入	模式	成员
无参数、debate 或 @all	debate	全部 5 个角色
<persona>	solo	该角色
debate <p1> <p2> ...	debate	列出的角色
@<unknown-preset>	error	拒绝并列出已知预设
<unknown-persona>	error	拒绝并列出 5 个角色
未带 debate 的 <p1> <p2> ...	error	拒绝并建议使用 ooo lateral debate <p1> <p2>

根据角色池验证每个角色名称；绝不静默转换。如果父级技能需要一个角色但未指定名称，则省略 persona，并在已知时传入 stagnation_pattern（spinning、oscillation、no_drift、diminishing_returns）；由服务选择角色（默认使用 contrarian）。

同时选择横向思维的 mode。如果用户面临多个选项之间影响重大的抉择（例如选择哪种数据库或架构），而不是陷入停滞，则使用 mode="decision"；否则省略 mode（默认为 unstuck）。在 decision 模式下，problem_context 描述各个选项，current_approach 描述当前倾向的选项（或 undecided）；省略 persona 表示进行完整辩论。只有在用户明确要求基于网络信息进行研究时，才传入 research=true；此操作较慢，绝非默认选项。

步骤 2：在调用 MCP 前收集必要上下文

如果 problem_context 或 current_approach 为空，该工具会直接失败，因此要先补齐两者（solo 和 debate 均如此）：

1. 复用父级技能或近期对话中的会话状态：problem_context（用户卡住的问题，用 1-3 句话描述）、current_approach（已尝试过的方法；"none yet, first attempt" 也可以），以及可选的 failed_attempts。
2. 如果无法恢复任一字段，使用当前运行时的 ask_user 功能向用户提出一个合并问题：“在进行横向思考之前，我需要了解两件事：(1) 你现在卡在哪个问题上？(2) 你已经尝试过什么？每项用一句话回答即可。”等待用户回答。绝不捏造这些字段；current_approach="not specified" 可以接受，但不得编造内容。

步骤 3：始终调用 ouroboros_lateral_think

每次调用都必须通过 MCP 工具路由，无论运行时环境如何，也无论是 solo 还是 debate；不得用直接扇出多个子 Agent 的方式替代。

加载 MCP 工具（延迟架构防护）

Ouroboros 工具可能会延迟加载，某一轮加载的架构可能在下一轮前卸载。每次调用 ouroboros_* 前，立即使用当前运行时的工具发现能力加载它："+ouroboros lateral" 用于 ouroboros_lateral_think；"+ouroboros conductor decision" 用于 ouroboros_record_conductor_decision（决策模式）。未加载架构的调用会失败，并显示 "Invalid tool parameters"。如果工具已经可以调用，则发现操作不会产生任何效果，预期结果为空。如果工具确实不存在（既未公开，也无法加载），请停止并报告 MCP 分发接口已损坏；不要擅自单独处理，也不要在没有它的情况下展开辩论。

调用时使用：

• 单人模式：persona=<one>、problem_context、current_approach、failed_attempts。
• 辩论模式：personas=[...]、problem_context、current_approach、failed_attempts。
• 另外提供步骤 1 中的 mode/research，以及在访谈或横向思维会话中运行时提供 session_id（它会绑定扇出操作，并拒绝来自其他会话的提交结果）。

步骤 4：根据响应形态采取行动（由服务端决定）

模式	插件响应	内联响应
单人模式	一个 _subagent 对象	content 中的一个 # Lateral Thinking: <approach> 区块
辩论模式	_subagents 数组（N 个对象）	由 \n\n---\n\n 连接的 N 个区块，以及一个包含相同 N 个负载的隐藏分发区块

内联分发区块（仅辩论模式，内联）。 如果响应 meta 中有结构化副本，优先使用它。否则，取 content 末尾 `` 之间的文本，对其进行 base64 解码并解析 JSON。未声明子 Agent 能力的宿主会收到中性形态：

{"dispatch_mode": "host_decides", "host_action": "dispatch_subagents_if_supported", "execution_preference": "parallel", "fallback_strategy": "sequential", "persona_count": N, "payloads": [...]}

显式指定顺序执行权限的宿主会收到 dispatch_mode="sequential" 和 legacy_dispatch_mode="inline_fallback"；后者仅为兼容性元数据。切勿按 --- 拆分连接后的显示文本：用户内容可能包含该分隔符。

形态 A：插件响应（OpenCode 插件模式）

插件会自行启动子任务。等待单个 _subagent 结果（单人模式）或所有 _subagents 结果（辩论模式），然后呈现或综合结果。如果响应是内联文本且不包含这两个键，则说明当前不在插件模式：使用形态 B。

形态 B：内联响应

分发区块会区分已声明的 host_driven、能力中立的 host_decides，以及显式的 sequential 执行。单人模式：呈现方案摘要、重新构建问题的提示词和待思考的问题，然后返回工作流。

辩论模式，运行时支持子 Agent 分发

1. 在简短的“横向思维工具包的建议”标题下展示可见的 Markdown。
2. 当使用 host_action="spawn_subagents"，或运行时具有原生并行原语时使用 host_action="dispatch_subagents_if_supported"，请使用当前运行时的 orchestrate_subagents 能力：为每个负载启动一个相互隔离的子任务，并同时启动；每个子任务都原样接收其 prompt 以及 context。
3. 等待所有子任务完成，并通过 result_correlation_key（通常为 context.persona）关联每个结果。
4. 可选的第 2 轮交叉质疑，仅在第 1 轮回答存在分歧时进行：向每个角色提供其他角色的简短摘要，并询问“指出每个摘要中的一个弱点。最多 200 字。”
5. 综合结果（见下文）。

辩论模式，不支持子 Agent 分发的受限运行时

如果响应带有 dispatch_mode="sequential"，或带有 dispatch_mode="host_decides" 且宿主没有原生并行原语，则按顺序处理每个已恢复的负载，通过 result_correlation_key 关联每个结果，并在最后一个负载处理完后综合结果。如果无法恢复任何负载（没有 meta 副本，也没有分发区块），则原样呈现处理器的 Markdown，并根据该文本综合结果；不进行第 2 轮。

综合（辩论，所有形态）

在决策模式下，遵循响应附带的综合约定：首先明确给出唯一一项建议，然后陈述依据（仅引用各角色实际获取的来源）、最有力的反对意见以及改变建议的条件。用户接受后，按照约定，主动提出使用 ouroboros_record_conductor_decision 将其记录下来。

在解困模式下，给出选项，而非结论：

## Debate result: N personas

### Options
- **Option A** (from <persona>): <one-liner>
- **Option B** (from <persona>): <one-liner>

### Disagreements
- <persona X> vs <persona Y>: <what they disagree about>

### Recommended (with reasoning)
<your single best read, labeled as your recommendation>

无论在哪种模式下，选择权都在用户手中：绝不代替用户自动进入下一步工作流。

RFC #1392 状态面包屑页脚

最终响应以且仅以一行 ◆ <current state> → next: <recommended action> 结尾。尽可能通过 ouroboros_session_status 根据实时会话状态确定状态，否则根据此技能的实际结果确定。绝不使用线性 Step N of M 页脚；如果下一步需要用户实际做出选择，则列出 2-3 个选项。