/critical-thinking

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 と同じ。書き手の答えは書き手の事実なので、本文に書いてよい。答えの中身はそのまま入れる(強めない、弱めない、答えにない数字や条件を足さない)。答えを本文に入れた分だけ本編は長くなるので、入れた字数と同じだけ、答えで要らなくなった断り書き(「〜は確認中」「〜は分かっていない」)や、決裁に要らない説明を削るか付録に回し、本編を