---

name: critical-thinking description: 仕事の文書(稟議書、提案書、企画書、報告書など、読んだ人に判断を求める文書)を、決裁者の目で検査して直すスキル。「決裁者の目で見て直して」「出す前に見て」「通る形にして」「稟議(提案書・企画書)をチェックして」と頼まれたら「決裁者の目で見て直す」の手順に従う。文書の中で答えが出ることは聞かずに直し、書き手にしか答えられない問いを3つまで聞いて答えを本文に入れ、確認事項は文書の外の別ファイルに出す。これが基本の入口。工程を分けて使うときは次の3つ。矛盾がないか、根拠を確かめて、ロジックが弱くないか、と検査だけを頼まれたら logic。そもそも前提は合っているか、他の選択肢はないか、何が起きたら覆るか、と頼まれたら somosomo(どちらも文書には書き込まず、行番号つきの問いと YAML で返す)。検査のあとで「指摘を反映して直して」なら「指摘を反映して直す」の手順、「構成から組み直して」「別の組み立てで」なら「構成から組み直す」の手順(事実と頼む中身は保ち、論の背骨だけ替える。構成案を出して書き手に選んでもらう)。「もっと端的に」「もっと丁寧に」なら「もっと端的に・もっと丁寧に」の手順(logic の YAML の深さで本編の長さを決める。事実と決裁事項は保つ)。日本語を自然にする・読みやすくする依頼には使わない(それは natural-japanese の仕事)。 license: MIT argument-hint: "[full|logic|somosomo|fix|short|detail|rebuild] <対象ファイル>(モードなしなら full と同じ)"

critical-thinking

仕事の文書の「考え」を、決裁者の目で検査して直すスキル。基本の入口は「決裁者の目で見て直して」の1つで、検査から直しまでを1回で通し、書き手には人にしか答えられない問いを3つまで聞く。検査は、文書の中で筋が通っているか(logic)と、文書の外から見て前提が合っているか(somosomo)の2つに分かれていて、工程を分けて使いたいときはそれぞれを呼べる。natural-japanese が日本語を直すのに対し、このスキルは中身を見る。

約束

• 元の文書はそのまま残す。検査では YAML と指摘を返し、直すかどうかは書き手が決める。直すときも、直した本文と確認事項は別のファイルに書く(書き手が元と見比べられるように)
• 使うのは文書にある事実・数値だけ。somosomo では「どんな材料があれば問いが閉じるか」の種類までを書き、材料そのものと結論は書き手に残す。文書にないことを足すと、書き手が言っていないことが書き手の言葉になる
• 指摘は書き手への問いの形で書く。「弱めるべき」「条件を足すべき」のような直し方は書かない。直し方を決めるのは書き手
• 指摘はすべて行番号で文書に紐づける。行番号で指せないものは書き手が探せないので書かない

呼び出し方

• /critical-thinking full <ファイル>、/critical-thinking <ファイル>(モードなし)、または「決裁者の目で見て直して」:全工程を通す。検査して、書き手に3つまで聞き、答えを入れて直し、直した文書から「もっと端的に」と「構成から組み直す」も作る。手順は「決裁者の目で見て直すよう頼まれたとき(全工程)」にある。迷ったらこれを使う

工程を分けて使う上級の呼び方は次の3つ。

• /critical-thinking logic <ファイル>:文書の中で筋が通っているかを検査する。論理構造を YAML に書き出し、主張と根拠の対応、矛盾、事実と推論の混在、並列の漏れやねじれ、どこにも対応しない文を指摘する。最初に references/logic.md を読む。YAML の漏れは scripts/coverage.py で見つけて埋める
• 「もっと端的に」「もっと丁寧に」:logic の YAML の木をどの深さまで本編にするかを決めて書き直す。手順は「もっと端的に・もっと丁寧にと頼まれたとき」にある
• /critical-thinking somosomo <ファイル>:文書の外から前提を疑う。主結論と論点を足場に、前提・問いそのもの・他の選択肢・覆る条件・利害と実行を問う。<ファイル>.logic.yaml が隣にあればそれを使い、なければ先に logic の YAML を作る。最初に references/somosomo.md を読む
• /critical-thinking fix <ファイル>、または「指摘を反映して直して」:検査の報告を本文に反映する。手順は「指摘を反映して直すよう頼まれたとき」
• /critical-thinking short <ファイル>、または「もっと端的に」。/critical-thinking detail <ファイル>、または「もっと丁寧に」:手順は「もっと端的に・もっと丁寧にと頼まれたとき」
• /critical-thinking rebuild <ファイル>、または「構成から組み直して」:手順は「構成から組み直すよう頼まれたとき」

サブコマンドで呼ばれたときも、自然言語で頼まれたときも、手順は同じ。

モードの指定がなければ、依頼の言葉で選ぶ。「矛盾がないか」「論理が通っているか」「根拠を確かめて」「ロジックが弱い」のように検査だけを頼まれたら logic。「そもそも」「前提を疑って」「本当にそうか」「他の選択肢は」「穴を探して」は somosomo。「指摘を反映して直して」は直す工程、「構成から組み直して」は組み直す工程。検査だけなのか直すところまでなのか分からなければ、決裁者の目で見て直す。

出力の共通形

1. 文書の性格を1行(何を決める文書か、誰が読むか。振り返りや経緯の記述なら、そう書く)
2. 主結論を1〜2文で。書き手の意図とずれていそうなら添える
3. 指摘を種類ごとに。各指摘は、行番号・本文の言葉・書き手への問い。文書全体で効くものから順に並べ、細かいものは件数で示す
4. YAML の保存先
5. 結び:「直すかどうかは書き手が決める。直すなら /natural-japanese <ファイル> で推敲できる」

同じ文書を2回検査すると、指摘の数や言い方は揺れる(LLM の読みに頼る検査で、lint のような再現性はない)。結果に一言添える。

指摘を反映して直すよう頼まれたとき

「指摘を反映して直して」は検査とは別の工程で、約束の「そのまま残す」は検査の側の話。問いに全部答えて本文に書き足すと、決める人が読む分量が増える。次の順で直す。

1. 決める人の論点を1つに決める。この文書を読んで何を決めるか(「PoC の予算を出すか」)。logic の YAML の 決裁事項 の欄から取る。本編は、その判断に要る節だけで組む。見出しは元の文書と同じ短い名詞句のままにし(「費用対効果」)、文や数字や【要確認】を見出しに入れない。結論は各節の最初の一文に書き、見出しと最初の一文だけ読んで筋が通るようにする
2. 答えられる問いは、本文の該当箇所を直して答える。矛盾はどちらかに揃え、計算は直す。文書にない事実は作らない。言い方の強さは根拠に合わせる。根拠がないのに言い切っている文は仮定や見込みの形に、根拠が文書の中にあるのに弱腰な文は言い切りに戻す。動かすのは言い方だけで、事実と根拠は動かさない。書く文、書き直す文には括弧の補足を入れない(「参考値(1件30分の削減)」は「参考値の1件30分の削減」、「解約できる(販売店に確認済み)」は「解約できると販売店に確認した」)。元の文書にある括弧も、文に開ける補足なら開く。残してよいのは、付録や章の参照、表の中の単位、略語の正式名称だけ。結論の根拠として挙げてよいのは、文書がその結論の根拠として書いているものだけで、文書の別の箇所にある事実を新しい根拠として結論につながない(書き手の判断の筋を変えることになる)
3. 答えられない問い(出典、実データ、まだ決まっていないこと)は、本文に書き足さず、文書とは別のファイル <元の文書名>.確認事項.md(拡張子を除いた名前に付ける。稟議書.md なら 稟議書.確認事項.md)に1行ずつ並べる。直した文書の中には確認事項の節を作らない。文書はそのまま出せる状態で返し、問いは文書の外に置く。書き手が確認事項を消し忘れたまま提出すると、決裁者が問いの一覧を読むことになるためだ。ファイルに書けない環境では、返答の中に同じ一覧を書く。本文では言い切りを仮定の形(「仮に月3時間とすると」)に変えるだけにする。ただし、文書の中で値や言い方が食い違っていて、どちらが正しいか書き手にしか分からないもの(対象は12名なのに費用は15名分、など)は、確認事項に回すだけでは読む人には元のまま見える。本文にも両方の値を並べ、「15名分(対象は12名。差の3名分は確認中)」のように食い違いを見せる。これなら読む人は確認中だと分かり、書き手の代わりに決めてもいない。「確認中」と書くのは、文書の2か所に違う値や言い方があるとき(12名と15名分)だけで、1つの食い違いにつき、最初に出る箇所で1回。2か所目以降は、最初の箇所と同じ値をそのまま書く。文書に答えがまだないこと(効果を判断する時期、何の数字で測るか、出典)は食い違いではなく未決で、本文は元の文書の文のまま(または仮定の形)にし、確認事項のファイルにだけ書く。「効果を判断する時期は確認中」のように未決に付けると、読む人は何が決まっていないかを数え直すことになる。本文に【要確認】のような印は埋めない。印を置きたくなった箇所は、そのまま確認事項の1行になる。検査の報告にある問いは、本文で答えたものを除いて、すべて確認事項に載せる。似た問いはまとめてよいが、落とさない。確認事項は「先に答える問い」(somosomo の報告で「決裁事項を倒しうる問い」とされたもの。3件まで)と「そのほか」の2つに分けて並べる
4. 書き手の代わりに決めない。日程・期限・担当・金額・目標値を新しく置かない。新しい施策や宿題を足さない。「〜と推定した」値を書かない。決めないと書けない箇所は、仮の形にとどめて確認事項のファイルに回す。矛盾を揃えるときは、文書にある2つの値のどちらかを選び、第3の値を作らない。YAML の 制約(上限額・時期・対象)は書き手が自分で置いた線なので、値を動かさない
5. 計算の前提、方式の比較表、機能要件、試算の感度表のような、判断の裏づけだが読まなくても決められるものは、付録に回す
6. 改訂の経緯は書かない。「第1版では〜としていた」のような本文の記述だけでなく、表紙や冒頭の版番号・改訂日・「指摘を反映」の注記も経緯にあたる。読む人は改訂の前を知らない
7. 直し終えたら、本編(付録を除く)の文字数を元の文書と比べる。長くなっていたら 1 に戻り、本編から外せる節を探すか付録に回す。元より長い本編は、直し終わっていない。確認事項は書き手が読むもので、決める人の分量には数えない
8. 最後に、natural-japanese で推敲する。問いに答えて書き足した文は、括弧の補足や言い換えが増えやすい。サブエージェントが使える環境では、直した文書だけを渡した別のサブエージェントに natural-japanese をかけさせ、段落ごとの確認を最後まで書き出させる(同じ文脈で続けると、長い工程の最後では省かれる)。使えなければそのまま呼び、natural-japanese 自体がなければ推敲していないことを返答に添える

返答には、直した箇所、確認事項のファイルに回した問い(一覧をそのまま)、書き手の代わりに選んだこと(矛盾でどちらに揃えたか)、本編の前後の文字数を書く。

決裁者の目で見て直すよう頼まれたとき(全工程)

「決裁者の目で見て直して」「出す前に見て」「通る形にして」と頼まれたら、検査から直しまでを1回の依頼で通し、直した文書から端的にした版と組み直した版も作る。AI に下書きを任せた人が読むのは、返ってきた文書と数行の説明だけ。だから、文書の中で答えが出ることは聞かずに直し、人に聞くのは人にしか答えられないことだけに絞る。

1. logic と somosomo を順に回す。報告は対象ファイルの隣に report-logic.md と report-somosomo.md として残す(すでにあれば読んで使い、回し直さない)。YAML も残す
2. somosomo の「決裁事項を倒しうる問い」から、書き手にしか答えられない問いを3つまで選ぶ。選べるのは、文書にない事実(件数、単価、契約条件、出どころ)、決裁者の論点の読み(「決めてもらうのは X だと読んだ。違うか」)、頼む範囲の判断(YAML の 決裁事項 の対象・金額・期間を変えるか)、の3種類。文書の中の数字や行どうしの突き合わせで答えが出る問い(矛盾、計算、言い切りの強さ)は、聞くかわりに「直す」の手順で自分で直す。3つに満たないときはそのままでよい
3. 聞く。対話できる環境では、本文を直す前に3つの問いをまとめて1回で聞き、「分からないものは分からないで結構です」と添える。対話できない環境(確認せずに進める指示、-p の実行)では、問いを対象ファイルの隣の questions.md に「1. 問い」の形で書いて、そこで終える。隣に answers.md があれば、それを書き手の答えとして読んで続ける
4. 答えを反映して直す。書き方は「指摘を反映して直す」の 1 から 8 と同じ。書き手の答えは書き手の事実なので、本文に書いてよい。答えの中身はそのまま入れる(強めない、弱めない、答えにない数字や条件を足さない)。答えを本文に入れた分だけ本編は長くなるので、入れた字数と同じだけ、答えで要らなくなった断り書き(「〜は確認中」「〜は分かっていない」)や、決裁に要らない説明を削るか付録に回し、本編を元より長くしない。直し終えたら字数を比べる(「指摘を反映して直す」の 7)。「分からない」「まだ調べていない」と答えられた問いは、2つに分ける。出す前に自分で調べられること(社内の規程や単価、担当部署に聞けば分かること、手元の記録で測れる数)は、本文に「まだ確かめていない」「確認中」「分からない」と書かず、元の文のまま(または仮定の形)にして、8 の宿題に回す。決裁者は、調べられることを調べていない文書を差し戻すので、告白を本文に書くと差し戻しの理由を自分で増やすことになる。やってみないと分からないこと(試験や診断で初めて分かる数、相手の反応)は、本文を仮定の形にして試験の条件として残し、確認事項のファイルに書く。書き手が決めることが残ったとき(目安をどの値にするか、合格の線をどこに置くか)も、本文に「確認中」と書かず、元の値のままにして宿題に回す。本文に「確認中」と書けるのは、文書の2か所に違う値があるときだけ(「指摘を反映して直す」の 3)。どちらも、どう確かめるかは元の文書が自分で書いている文(「現状診断で確認します」など)をそのまま使い、元の文書に確かめ方がなければ仮定の形にとどめる。新しい段取りや作業(「台帳から確かめる」「〇〇で測る」)を書くと、書き手の代わりに作業を決めたことになる。人に聞く問いを3つに絞ることと、直す範囲を絞ることは別で、文書の中で直せる指摘(矛盾、計算、言い切りの強さ、並びのねじれ、根拠のない事例の扱い)は聞かずにすべて直す。確認事項は「先に答える問い」(聞いて分からなかった問いと、聞かなかった問いのうち書き手の判断が要るもの。3件まで)と「そのほか」(残りの問いを1行ずつ。落とさない)に分ける
5. 答えによって決裁事項の前提が崩れたとき(課題の大きさが小さい、原因が別、費用が見合わない)だけ、縮小案を出す。「費用が見合わない」は、答えの数字から出る効果の上限(課題をすべて解決した場合の額)が、文書が自分で置いている期間(契約や試験の期間。なければ1年)の費用を下回るときと読む。何年で回収するかの物差しが文書にないことは、崩れていない理由にならない(物差しがないこと自体を確認事項に書く)。崩れたときは、「組み直す」の「頼む中身を小さくする案」を1行で添える。同じ1行を、確認事項のファイルの先頭(先に答える問いの前)にも「頼む中身を小さくする案」として書く(返答は流れるが、ファイルは書き手が提出前に読み返す)。選ぶのは書き手で、本文は頼む中身を保ったまま直す。そのうえで、縮小案で書いた版も <名前>.review.縮小.md に別に出す(決裁事項と頼む範囲だけを縮小案のとおりに変え、事実と数値はそのまま。書き方は「指摘を反映して直す」と同じ)。書き手は2つを見て選ぶ。縮小版の確認事項は <名前>.review.縮小.確認事項.md に書く
6. 直した文書を <名前>.review.md に保存し、確認事項は <名前>.確認事項.md に書く。稟議書.md なら 稟議書.review.md と 稟議書.確認事項.md になる。元のファイルは変えない
7. 直した文書に「もっと端的に」を回し、<名前>.review.short.md に保存する。手順は「もっと端的に・もっと丁寧にと頼まれたとき」のとおりで、logic の YAML は直した文書で作り直す。続けて「構成から組み直す」を回し、構成案を <名前>.review.plans.md に、組み直した本文を <名前>.review.rebuild.md に保存する。手順は「構成から組み直すよう頼まれたとき」のとおりで、対話できない環境では頼む中身を保つ案から1つ選ぶ。どちらも直した文書を元にし、確認事項が出れば <名前>.review.short.確認事項.md と <名前>.review.rebuild.確認事項.md に書く。書き手が読むのは直した文書で、端的にした版と組み直した版は、提出先や分量に合わせて選べるように並べておくもの
8. 返答の先頭に判定を書く。差し戻しにするのは次の3つのどれかがあるときだけ。文書自身が「未確認」「確認中」「集計中」「契約前に確認する」と書いていることのうち、出す前に調べられるもの。書き手の答えで「まだ調べていない」と分かった、出す前に調べられること。答えで決裁事項の前提が崩れたこと(費用に見合わない、原因が別、課題の大きさが違う)。どれかがあれば「このままでは差し戻されます」、なければ「このまま出せます」。読み手が気にしそうなことを新しく思いついて宿題にしない(それは確認事項の「そのほか」に書く)。宿題が終われば出せる、という状態に収束させるためである。差し戻しなら、理由を決裁者の言葉で1〜2行(「規程の確認と2週間の測定は、承認前に自分でできることだから」)と、出す前にやることを、決裁事項を倒すものから順に書く。返答には先頭の3つまでを書き、残りがあれば件数だけ添える。確認事項のファイルには、差し戻しの理由になるものを全部書く(3つに絞って残りを落とすと、宿題を済ませても次の回でまた差し戻しになる)。1つにつき、何を調べるか、誰に聞くか・何を見るか、答えが出たら本文のどこをどう書き換えるか、の3点(「経理部に単価の税区分を聞く → 3章の表を税込で引き直し、目安を39分か43分に決める」)。調べるのは書き手で、書き換え方はここで用意しておく。同じ宿題を、確認事項のファイルの先頭に「出す前にやること」として書く(縮小案より前)。そのあとに、出したファイルの一覧と、それぞれの本編の字数、聞いた問いを反映したか仮定にしたか、絞る案があればその1行と縮小版の保存先。検査の報告は読みたい人のためにファイルで残す。3の問いで止まったときは、問いの保存先と、答えを answers.md に書けば続きを回せることを書く

構成から組み直すよう頼まれたとき

「構成から組み直して」「別の組み立てで」「決裁者に通る形に」と頼まれたら、指摘を1つずつ直すのではなく、論の背骨を替える。AI に下書きを任せた人は構成を自分の頭の中に持っていないことが多く、構成を替えて見せるのはこの工程でしかできない。

保つものと捨てるものを先に決める。

• 保つ:事実、数値、出典、主結論、決裁や承認を求める事項(何を頼むか)、書き手の制約(上限額、時期、対象の範囲)。これらは元の文書の文をそのまま使う。logic の YAML の 決裁事項 と 制約 の欄に本文の文が写してあるので、そこから取る
• 捨ててよい:どの理由を先頭に置くか、何を本編に残し何を付録に回すか、申請や報告をどう枠づけるか(「ツールを導入する稟議」を「6か月で3つの問いに答える試験の稟議」と読み替える、など)。「どう頼むか」は変えてよく、「何を頼むか」は変えない。例外は次の「頼む中身を小さくする案」で、そこだけは何を頼むかを縮めてよい

次の順で進める。

1. 検査の報告(logic と somosomo)がなければ、先に logic を回す。somosomo の問いは、枠を替える材料になるので、あればそれも読む
2. 構成案を2つか3つ出す。各案は、主張(この文書が決める人に言うこと)を一文、本編の見出しの骨組み、その案が答える検査の問い(番号で)、弱点を1行。案どうしは材料の違いではなく背骨の違いで分ける。案は文書にある事実と頼む中身だけで作る
   • 案のうち1つは「頼む中身を小さくする案」にする。検査の問いが、決裁事項そのものの前提(課題の大きさ、原因、効果の見込み)を疑っているとき、頼む中身を保ったまま段取りを替えるだけでは、問いに答えたことにならない。この案では、決裁事項を縮める(期間・金額・対象を減らす、前段だけを頼む、2回に分けて頼む)か、頼む前に置くべきことを先に置く(読み手や書き手の手元にある材料で確かめられることを、先に確かめる)か、頼むこと自体を取り下げる。縮める・分ける・先にする・取り下げるだけで作り、文書にない施策や事実は使わない。どの検査の問いの答えが出ると元の決裁事項が倒れるかを、問いの番号と行番号で書く。縮めた決裁事項は元の文書の言葉で書く
   • 検査の問いが決裁事項の前提を疑っていないときも、この案は出す。その場合は弱点に「問いの答えは出ているので、縮める理由は薄い」と書けばよい
3. 書き手に1つ選んでもらう。本文を書くのは、書き手が選んでから。確認せずに進めるよう言われているときは、案を返答に残したうえで、頼む中身を保つ案の中から1つを選び、選んだ理由を書く。頼む中身を小さくする案は書き手にしか選べないので、返答の先頭に置き、「この案を選ぶなら、どの問いの答えを先に見るか」を添える
4. 選んだ案で本文を書く。書き方は「指摘を反映して直す」の 2 から 8 と同じ。本文と確認事項のファイルでは、問いの中身を言葉で書く(L1、S3 のような番号は検査の作業用で、読む人には通じない)
5. 書き終えたら、主結論と決裁事項が元の文書と同じ中身かを読み比べる。変わっていたら、組み直しではなく書き手の代わりに決めているので、元に戻す。書き手が「頼む中身を小さくする案」を選んだときだけ、決裁事項は意図して変わる。その場合は、元の決裁事項の文と縮めた文を返答に並べて書く

返答には、出した案(頼む中身を小さくする案を先頭に)と選んだ案、保ったもの(主結論と決裁事項の文)、捨てた背骨、確認事項に回した問い、本編の前後の文字数を書く。

もっと端的に・もっと丁寧にと頼まれたとき

「もっと端的に」「短くして」「もっと丁寧に」「根拠を厚く」と頼まれたら、文章を削ったり膨らませたりするのではなく、logic の YAML の木をどの深さまで本文にするかを決めて書き直す。AI の書いた文書が長いのは根拠を量で並べるからで、YAML の主張・論拠・重みを見れば、どこまで要るかを先に決められる。

保つものは「構成から組み直す」と同じ。事実、数値、出典、主結論、決裁や承認を求める事項、書き手の制約は、どちらの向きでも元の文書の文をそのまま使う。丁寧にするときも、書けるのは YAML にあることだけ。文書の中の矛盾や数値の食い違いは、この工程ではそのまま残す(直すのは「指摘を反映して直す」の仕事)。食い違う値は両方残し、確認事項のファイルに1行で書く。

1. <ファイル>.logic.yaml がなければ、先に logic を回す。YAML に 論拠・重み・決裁事項 がない古い形なら、logic を回し直す
2. 端的にするとき。本編に残すのは、主結論、各論点の主張と 重み: 決裁に要る の根拠、決裁事項 と 制約(YAML の欄の文のまま)。比べた案 が本文にあれば、その案を選ばなかった理由の根拠は「決裁に要る」として残す。裏づけ と 補足 の根拠と「限界や条件」は付録に移す。事実・数値・事例は、端的にしても文書のどこかに残す(端的 → 丁寧 → 端的 と往復しても同じ文書に戻れるようにするため)。論点のうち主結論の 依存 に入っていないものは本編から外し、付録に移す。各節は、主張の一文と、決裁に要る根拠の一文か一表で書く。本編に残す根拠がなくなった論点は、節ごと付録に移す(「付録Dを参照」のような案内だけの節は、決裁の材料にならない)
3. 丁寧にするとき。本編に、裏づけ の根拠と「限界や条件」を戻し、論点ごとに 論拠 を一文で書く。論拠が「本文にない」ものは、書き手の代わりに補わず、その論点を確認事項のファイル(「指摘を反映して直す」の 3 と同じ形)に回す。根拠は YAML にあるものだけを使う。丁寧にしても、本編は元の文書より長くならないのがふつうで、長くなったら YAML にないものを足していないか見直す
4. どちらの向きでも、書き方は「指摘を反映して直す」の 4 から 8 と同じ(書き手の代わりに決めない、改訂の経緯を書かない、見出しは短い名詞句、最後に natural-japanese で推敲する)
5. 書き終えたら、主結論と決裁事項と数値が元の文書と同じかを読み比べ、違っていたら元の文に戻す。端的にした文書の本文の各文は、元の文書のどの行から来たかを言える。言えない文は、元の文に戻すか削る

返答には、本編の前後の文字数、本編に残した根拠と付録に移した根拠の数、論拠が本文にないため確認事項に回した論点を書く。

参考にした枠組み

縦の論理(本当にそうか)と横の論理(それだけか)、飛躍の3つの原因は高田貴久『ロジカル・プレゼンテーション』、問いそのものを疑う見方は内田和成『論点思考』から借りている。言い回しは借りず、問いの型だけを使う。2冊の要点と、このスキルのどこに当たるか、まだ足りないものは references/foundations.md にまとめている。