unstuck

/unstuck — 行き詰まりを打開する

「不可能」をさまざまな切り口に変えます。壁の種類を分類し、それに合った水平思考のテクニックを使って取り組み、最初の凡庸な回避策で終わらせません。実行可能な切り口と次のアクションを提示するか、正直に「この壁は構造上必要なものなので、目標を変更しましょう」と伝えます。

2 つのモード：

• ユーザーによる呼び出し — 行き詰まった人から相談があった場合です。以下の 7 ステップのワークフローをすべて実行します。
• エージェントの最短ルート — エージェントであるあなたが、タスクの途中で壁にぶつかった場合です。できないとユーザーに伝える前に、エージェントの最短ルートを実行してください。

考え方：壁には種類があり、種類に応じて使うバールが決まります

「不可能」は事実ではなく、主張です。ほとんどの場合、より弱い主張に分解できます。たとえば、費用がかかる、ルールに反する、誰もやったことがない、やり方がわからないなどです。セッションを終わらせるのは、本当に不可能な場合（物理法則、数学、算術）だけです。その場合は、正直に伝えてセッションを終えます。

壁の種類	「不可能」が実際に意味すること	主なテクニック（references/techniques.mdを参照）
思い込み	誰も再確認していない、受け継がれた信念	T1 思い込みの解剖、T3 第一原理
問題の捉え方	目標の表現方法が、答えを除外している	T4 抽象度の変更、T2 逆転、T5 逆算
門番	人や組織から断られた	T10 拒否の理由を問いただす、T6 類推による転用
ツール／技術	「X は Y に対応していない」	T9 SCAMPER（基本要素を置き換える）、T6 類推による転用
リソース	時間／資金／人員が足りない	T7 制約の切り替え、T8 挑発
物理法則／数学	本当に不可能（まれ）	正直に切り上げる — 目標を変更する。この壁は構造上必要なものです

ステップ 1 — 壁を把握する

ユーザーから、次の情報を構造化したメッセージ 1 つで聞き取ります（何度もやり取りしません）。

• 目標 — 最終的に何をしようとしていますか？（行き詰まっている手順ではなく、それが役立つ作業全体です。）
• 壁 — 具体的に何が障害になっていますか？
• 試したこと — これまでに何を試しましたか？
• 拒否の根拠 — 誰が、または何が拒否しましたか？物理法則ですか？ベンダーのドキュメントですか？人ですか？エラーメッセージですか？それとも、自分自身の思い込みですか？
• 重要度と期限 — この壁を乗り越えることはどれほど重要で、いつまでに必要ですか？

ユーザーが「何でも試しました」と言ったら、試したことを列挙してもらいます。「何でも」といっても、通常は 2～3 個です。

ステップ 2 — 壁を分類する

上記の分類を使います。分類とその理由を伝えてください。次の 2 つのルールに従います。

1. 「不可能」という言葉を分解する。 その言葉を使わずに壁を言い換えます。「費用がかかる」「ドキュメントに記載がない」「相手に断られた」「やり方がわからない」などです。言い換えることで、壁の種類が明確になることがよくあります。
2. 先に進む前に、問題を異なる 2 つの抽象度で言い換えます。1 つはより抽象的なレベル（この作業は何のためのものか？）、もう 1 つはより具体的なレベル（具体的に、どの手順で何が失敗するのか？）です。抽象度を変えるだけで壁が消えることも多くあります。壁が消えた場合はそれを伝え、ステップ 6 に進みます。

ステップ 3 — 思い込みを解剖する（必ず実行）

壁の種類にかかわらず、references/techniques.mdの T1 を実行します。問題の記述に含まれるすべての思い込みを列挙し、それぞれに確認済みの事実か受け継がれた信念かの印を付け、信念に異議を唱えます。ここでほとんどの壁は解消されます。解消されない場合も、ステップ 4 に向けて問題を正しく捉えられます。

ステップ 4 — 選定したテクニックを実行する

壁の種類に応じて、さらに 2～3 個のテクニックを選びます（表の主なテクニックを参照してください。選定の詳しい指針はreferences/techniques.mdにあります）。各テクニックから、2～3 個の切り口を出します。

発想のルール：

• 数の条件：評価を始める前に、切り口を合計 10 個以上出します。 最初の回避策は、たいてい凡庸です。発想中は評価せず、実現可能性について話さず、「でも」とも言いません。
• 切り口は、バリエーションではなく種類の異なるものにしてください。「もう一度、もっと丁寧に頼む」という 3 種類の案は、切り口としては 1 つです。
• この段階では、突飛な切り口も歓迎します。ステップ 5 で絞り込みますが、実現可能な案のきっかけになることもよくあります。

ステップ 5 — 可能性を仕分ける

すべての可能性を次のように分類します。

• 今すぐ試す — 手元にあるもので実行可能で、具体的な最初のアクションがある
• 調査が必要 — 未確認事項が問題ないとわかれば実行可能 → /deep-research に回す
• 突飛だが30分試す価値あり — 成功率は低く、コストはわずかで、見返りは非対称に大きい
• 却下 — 実際の制約に反する（どの制約かを明記する）

ステップ 6 — 決定する

• 具体的な次のアクションを添えて、1〜3個の可能性を選びます。
• 実行可能な可能性が2つ以上あり、互いに両立しない場合 → 分岐を /decide に回します。
• トリアージを通過したものが何もなく、壁が物理学や数学の法則である場合は、率直にそう伝えます。「壁は構造上避けられません — 目標を別の方向に切り替えましょう」は、正当で成功した出力です。 方向転換後の目標案を提案します。

ステップ 7 — アーカイブする

アーカイブは ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/unstuck/archive/ に保存します（存在しない場合はディレクトリを作成してください）。スキル自体のフォルダー内にはアーカイブを保存しないでください。スキルのインストールやアップグレード時に、ソースから再同期されて保存内容が消去されます。

<archive dir>/<YYYY-MM-DD>-<slug>.md に書き込みます。

# Wall: <one-line>

**Date:** YYYY-MM-DD
**Invoked by:** user | agent
**Wall type:** assumption / framing / gatekeeper / tool / resource / physics
**Goal it blocked:** <one line>

## The wall as stated
<verbatim>

## The wall decompiled
<restated without "impossible">

## Assumptions attacked
- <belief> → <held / broke>

## Techniques run
T1, T4, T7 — <one line on what each surfaced>

## Angles (all of them)
1. <angle> — try now / research / wild / dead
2. …

## Committed
**<the angle(s) chosen>** — next action: <concrete step>
(or: "Wall is load-bearing — rerouted goal to <X>")

## Outcome (fill in later)
<did the angle work?>

<archive dir>/INDEX.md に追記します（存在しない場合は作成してください）。

- 2026-07-14 — [<wall>](./<filename>.md) — <type> — **<committed angle or "rerouted">**

時間が経つと、これはパターンライブラリになります。grep で検索すれば、どの手法が実際に自分の壁を崩せたか、どの種類の壁が繰り返し現れるか（繰り返し現れる壁は、たいてい上流に未検討の前提があります）を知ることができます。

エージェント向け最短手順

エージェントであるあなたが、タスクの途中で壁にぶつかった場合に使います。発動条件：API／ツールが必要な機能に対応していない、あるアプローチが2回失敗した、または回答の中で「それはできません」「残念ながら」「唯一の選択肢は」という文を言いかけていることに気づいた場合。

行き詰まりをユーザーに報告する前に、インラインで実行します（対話形式での聞き取りは不要です。壁はすでに文脈に含まれています）。

1. 分類 — 壁を分類体系に沿って分類します — 1行で記載します。
2. 検死 — 自分の捉え方に含まれる前提を3〜5個挙げ、引き継いだ思い込みに印を付けます。（「カーソルはテキスト文字でなければならない」「これはクライアント側で起きなければならない」「API が唯一の手段だ」）
3. 壁の種類に合った手法を2つ実行し、インラインでの問題解決では最低5つの可能性を出します。最終的に行き詰まりをユーザーに報告する場合は、その前に10個の可能性をすべて検討してください — 行き詰まりの報告こそ、この条件が設けられている理由です。
4. その後、次のいずれかを行います。
   • 実行可能な可能性がある → それを使って進めます（直面した壁と採用した可能性をユーザーに伝えます）。
   • 実行可能なものがない → 可能性の一覧を添えて行き詰まりを報告します。試したこと、検討したこと、それぞれがなぜ却下されたかを示します。「対応していません」とだけ伝えることは避けてください。
5. 壁が些細なものでなかった場合は、実行内容をアーカイブします（ステップ 7 の形式で、Invoked by: agent と記載）。1分未満で解決した壁はアーカイブ不要です。

成功の指標は、試した可能性の記録を示さずに行き詰まりを報告することがなくなることです。

連携するスキル

• decide — 下流：互いに両立しない実行可能な可能性が2つ以上あれば、/decide に分岐を渡します。上流：不足している情報が情報そのものではなく選択肢である場合、decide の Q19（「どの不足情報が判断を変えるか？」）からこちらに回すことができます。
• deep-research — 「調査が必要」な可能性はそちらに回します。調査の概要が戻ったら、ステップ 5 に再び進みます。
• business-brainstorm — Kill 判定での「盗める切り口」という手法は、このスキルをビジネスアイデアに適用したものです。
• pm — 決定した可能性をボードのタスクにします。
• second-brain — アーカイブの項目をまとめて、「乗り越えた壁」の Wiki ページを作成できます。

ガードレール

• 同意、法律、倫理に関する拒否は、尊重すべき明確な拒否です。 このスキルが迂回するのは技術的な壁や想像力の壁であり、人の境界線ではありません。壁が「相手が明確に拒否した」ということであれば、取るべき行動は「相手が喜んで開いてくれる別の扉はないか」を探ること（T10）であり、閉じた扉を押し続けることではありません。
• 時間を区切る：20〜40分。 これはバールであって、哲学のゼミではありません。時間内に突破口が見つからなければ、試したことをアーカイブし、再検討の予定を立てるか、別の方向に切り替えます。
• 根拠のある撤退は、根拠のない前向きさに勝ります。 実際に試したうえで、壁は構造上避けられないと判断するのは成功です。漠然とした苛立ちを、明確な方向転換に変えられます。

品質に関するメモ

• 問題の言い換えが作業の半分を占めます。「不可能」な問題の多くは、提示されたとおりでは不可能です。テクニックを試す前に、2つの高度から言い換えてください（ステップ 2）。必ず実施します。
• **数の条件を形骸化させないでください。**実際は3つの角度を装いで10個に見せかけたものでは、条件を満たせません。種類が異なる必要があります。
• 試したことのリストは、試した雰囲気よりも重要です。「何でも試しました」と言われたら、実際のリストを確認してください。「何でも」とそのリストの間にある差に、たいてい答えが見つかります。
• **失敗も記録に残してください。**今日突破できなかった壁も、角度の一覧とともに保存しておけば、状況が変わったときに5分で再検討できます。最初からやり直す必要はありません。