mcpField
U
unstuck

unstuck

github.com/q00エージェントワークフロー6.3k71 回インストール1 日前に更新
リポジトリ

unstuck について

unstuck は、1人または複数の視点から停滞した作業や難しい選択を捉え直す Ouroboros のスキルです。ソロとディベートに対応し、実行には MCP ツールを使います。

主な機能

  1. 01ソロまたは複数視点のディベート
  2. 025つの再考ペルソナ
  3. 03停滞・意思決定モード
  4. 04任意のウェブ調査

活用シーン

  1. 01停滞した作業の打開
  2. 02重要な選択肢の比較
  3. 03問題の前提への異議

MCP 対応

各実行で Ouroboros の MCP ツール `ouroboros_lateral_think` を呼び出します。呼び出し前に必要な背景情報を集めます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/q00/ouroboros --skill unstuck

インストール後、Claude Code で/unstuckを入力して読み込まれたか確認します。

詳細

/ouroboros:unstuck

停滞を打破したり、難しい選択について助言したりするために、水平思考のペルソナを活用します。Solo は1つのペルソナを実行し、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、または @alldebate5つすべてのペルソナ
<persona>soloそのペルソナ
debate <p1> <p2> ...debate指定されたペルソナ
@<unknown-preset>error拒否し、既知のプリセットを一覧表示する
<unknown-persona>error拒否し、5つのペルソナを一覧表示する
debate を含まない <p1> <p2> ...error拒否し、ooo lateral debate <p1> <p2> を提案する

すべてのペルソナ名をプールと照合して検証してください。黙って別の名前に置き換えてはいけません。親スキルがペルソナを1つ必要としているものの名前を指定していない場合は、persona を省略し、既知であれば stagnation_pattern(spinning、oscillation、no_drift、diminishing_returns)を渡してください。サーバーがペルソナを選択します(デフォルトは contrarian)。

水平思考のモードも選択してください。ユーザーが停滞しているのではなく、重大な選択肢の中から選ぼうとしている場合(どのデータベースにするか、どのアーキテクチャにするかなど)は、mode="decision" を使用してください。それ以外では mode を省略します(デフォルトは unstuck)。decision モードでは、problem_context に選択肢を、current_approach に現在有力な選択肢(または undecided)を記述します。ペルソナを省略すると、全面的な debate が実行されます。ユーザーがウェブ情報に基づく調査を明示的に求めた場合に限り、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点確認させてください。(1)今、何に行き詰まっていますか?(2)これまでに何を試しましたか?それぞれ一文で十分です。」回答を待ってください。これらのフィールドを作り上げてはいけません。current_approach="not specified" は許容されますが、内容を捏造してはいけません。
ステップ 3:必ず ouroboros_lateral_think を呼び出す

ランタイムを問わず、solo と debate の両方を含むすべての呼び出しを、MCP ツール経由で実行してください。直接サブエージェントを並列起動して代用してはいけません。

MCP ツールの読み込み(遅延スキーマのガード)

Ouroboros ツールは遅延読み込みされる場合があり、あるターンで読み込んだスキーマが次のターンまでにアンロードされることがあります。各 ouroboros_* 呼び出しの直前に、アクティブなランタイムのツール検出機能を使って読み込んでください。ouroboros_lateral_think には "+ouroboros lateral"、ouroboros_record_conductor_decision(decision モード)には "+ouroboros conductor decision" を指定します。スキーマが読み込まれていない状態で呼び出すと、"Invalid tool parameters" で失敗します。ツールがすでに呼び出し可能な場合、検出処理は何もせず、空の結果が返される想定です。ツールが本当に存在しない場合(公開も読み込みもできない場合)は、MCP のディスパッチ面が壊れていることを報告して停止してください。独断で対応したり、ツールなしで議論したりしないでください。

以下を指定して呼び出します。

  • Solo:persona=<one>、problem_context、current_approach、failed_attempts。
  • Debate:personas=[...]、problem_context、current_approach、failed_attempts。
  • さらに Step 1 の mode/research を指定し、インタビューまたは lateral セッション内で実行する場合は session_id も指定します(これによりファンアウトが紐付けられ、別のセッションから送信された結果は拒否されます)。
Step 4:応答の形式に基づいて対応する(形式はサーバーが選択します)
モードプラグイン応答インライン応答
Solo1 つの _subagent オブジェクトcontent 内の # Lateral Thinking: <approach> ブロック 1 つ
Debate_subagents 配列(N 個のオブジェクト)\n\n---\n\n で結合された N 個のブロックと、同じ N 個のペイロードを含む非表示のディスパッチブロック

インラインディスパッチブロック(Debate、インラインのみ)。 応答メタに構造化されたコピーがある場合は、そちらを優先してください。ない場合は、content の末尾にある `` の間のテキストを取得し、base64 デコードして JSON を解析します。サブエージェント機能を宣言していないホストには、中立的な形式が返されます。

{"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 結果(Solo)またはすべての _subagents 結果(Debate)を待ってから、提示または統合してください。応答がどちらのキーも含まないインラインテキストの場合、プラグインモードではありません。形式 B を使ってください。

形式 B:インライン応答

ディスパッチブロックにより、宣言された host_driven、機能に依存しない host_decides、明示的な sequential 実行が区別されます。Solo:アプローチの要約、再構成のためのプロンプト、検討すべき質問を提示してから、ワークフローに戻します。

Debate、ランタイムがサブエージェントのディスパッチをサポートする場合
  1. 「ラテラルシンキングのツールキットによる提案」などの短い見出しを付けて、表示されている Markdown を示します。
  2. host_action="spawn_subagents"、またはランタイムにネイティブの並列プリミティブがある場合は host_action="dispatch_subagents_if_supported" を使い、アクティブなランタイムの orchestrate_subagents 機能を使用します。各ペイロードにつき 1 つの独立した子エージェントを同時に起動し、それぞれに prompt をそのまま渡し、あわせて context も渡します。
  3. すべての子エージェントの完了を待ち、result_correlation_key(通常は context.persona)で各結果を対応付けます。
  4. Round 1 の回答が食い違う場合に限り、任意で Round 2 の相互批判を行います。各ペルソナに他のペルソナの短い要約を渡し、「それぞれの弱点を 1 つ指摘してください。200 語以内。」と尋ねます。
  5. 統合します(下記参照)。
Debate、サブエージェントのディスパッチができない制約付きランタイムの場合

応答に dispatch_mode="sequential" が付いている場合、または dispatch_mode="host_decides" が付いていてホストにネイティブの並列プリミティブがない場合は、復元された各ペイロードを順番に処理し、すべての結果を result_correlation_key で対応付けて、最後の結果の後に統合します。復元可能なペイロードがない場合(メタのコピーもディスパッチブロックもない場合)は、ハンドラーの Markdown をそのまま提示し、そのテキストから統合します。Round 2 は行いません。

統合(ディベート、すべての形状)

意思決定モードでは、応答に含まれる統合契約に従います。最初に推奨事項を1つだけ述べ、その根拠(ペルソナが実際に取得した情報源のみを引用)、最も有力な反対意見、判断を覆す条件を示します。ユーザーが受け入れた後、契約に記載されているとおり、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> の形式の行を1行だけ記載します。利用可能な場合は ouroboros_session_status でライブセッションの状態を確認し、そうでない場合は、このスキルで実際に得られた結果から状態を判断します。Step N of M の形式のフッターは使用しないでください。次の手順が実際に選択可能な場合は、選択肢を2〜3個挙げてください。

コメント