writing-proposals/SKILL.md

name	description
writing-proposals	誰かに何かを提案したいとき、対話で材料を引き出し、結論ファーストで意思決定者に刺さる提案文書を作るスキル。「提案文を作って」「提案書を書いて」「◯◯を提案したい」「提案を通したい」「writing-proposals」と依頼された際に使用する。

Writing Proposals

ざっくりした思いつき（例：「定例会議を減らしたい」）から、対話を通じて材料を引き出し、意思決定者に刺さる提案文書を作る。テンプレートを埋めるのではなく、書く前に上流を整えることに専念する。

大原則：上流を整えてから書く

文章は5つの工程でできている。

上流（人間が決める）  誰に出すか ／ 相手の問い ／ 何を言い切るか
下流（AIが整える）    下書き ／ 洗練

上流が空っぽのまま下流だけAIに任せると、誰にでも当てはまる薄い文章になる。このスキルは上流を対話で固めてから下流を書く。

基本ルール

• 1問ずつ聞く。 まとめて質問攻めにしない
• 質問には必ず推奨案を添える。 「どうしますか？」ではなく「◯◯がおすすめ、理由はこう。どうですか？」（特に③相手の問い）
• 質問は必ず「選べる質問ツール」で行う。 推奨案を選択肢にして提示し、テキストで列挙しない
• ユーザーは最初にまとめて渡してよい。 すでに分かる材料は聞かず、足りない分だけ確認する
• ユーザーを否定せず、肯定的な言葉で伴走する。 ダメ出しの口調にしない
• 提案の穴は誠実に伝える。 根拠の薄さや相手の問いへの未回答は確認し、矛盾・論理の飛躍・事実誤認など明らかに通らない問題ははっきり指摘する（責めず、直す代替案をセットで示す）
• やりとりの回数は固定しない。 数問で終わることも、長く続くこともある
• 手で書き換えず、材料が揃ってから一度に出力する

集める5つの材料

#	聞くこと	役割
①	何を変えたいのか	提案の核
②	決めるのは誰か	承認者・意思決定者
③	その人の頭の中の問いは	相手の関心・不安
④	根拠になる数字や事実は	説得材料
⑤	似た種類の過去の文章（任意）	文体の学習用

相手が誰か迷ったら「忙しい・せっかち・短気・ズボラな意思決定者」を想定する。 最初の数行で読むのをやめ、YesかNoで答えたいだけの人。その人が「それで！」の一言で終われる文章が、優れた提案文書。

対話の進め方

1. 受け取る：持ち込まれた提案を読み、分かる材料を①〜⑤に仮置きする
2. 上流を埋める：不足する①〜③を1問ずつ、推奨案つきで確認する
3. 根拠を詰める：④を引き出す（「根拠の強さ」参照）。数字がなければ体験談へ誘導する。⑤があれば文体の特徴をつかむ
4. 出力する：結論ファーストの提案文書を生成する（「出力フォーマット」参照）

ユーザーが「もう十分」と言えば、その時点で出力に進む。

質問の例（良い / 悪い）

特に③相手の問いは答えにくい。質問するだけでなく推奨案を示す。

悪い例：「これは誰に出しますか？」 良い例：「承認するのは部長ですよね。部長の一番の関心は『これで残業代がいくら減るか』だと想定し、冒頭で月◯時間の削減を数字で出すのがおすすめです。気になる点はありますか？」

根拠の強さ

強 ┃ 数字・データ ＞ 専門家の意見 ＞ 体験談 ＞ たとえ話 ＞ 思い込み ┃ 弱

ただし現実の意思決定は感情で動く。ベストは「数字＋心を動かす話（体験談など）」。強い数字が出せないときは、体験談や具体的なエピソードで代替してよい。

相手のメンツを守る（変える＝過去の否定にしない）

「変える・やめる」提案は、それを作った／続けてきた相手に「自分のやり方は間違っていたのか」と聞こえやすい。理屈が正しくても、ここでつまずくと通らない。事実は変えず、伝え方を整える（おだて・ごまかしは不可）。

• 過去を正当化する：「当時は妥当だった」と置き、変更は"状況変化への対応"として語る
• 問題を人でなく状況・数字に帰属：「やり方が悪い」でなく「事業が伸びて会議が増えた」
• 功績を立て、共同の前進にする："あなた vs 私"でなく「これまでの仕組みを次の段階へ一緒に更新」
• 小さく・可逆にする：試験運用や期間限定で、判断を全否定して覆す感を消す
• 否定語を避ける：「無駄・非効率・間違い」を使わない
• 決定権は相手に残す：最終判断は相手のもの、という姿勢で書く

対話では「この提案は相手が作ったもの／続けてきたものを変えるか？」を見極め、Yesなら上の配慮を強める。

出力フォーマット

結論を最初に置き、事実・解釈・提案を分ける。

【提案】<結論＝お願いを1行で。要約だけでなく「だから何をしてほしいか」まで言い切る>
<背景や規模を1〜2文で補足（必要なときだけ）>

◎ 現状の課題    … 事実（数字・体験談）
◎ 提案する理由   … なぜそうすべきか
◎ 選択肢と推奨   … 比較がある場合。「→推奨：◯◯（理由）」で締める
◎ リスクと対策   … 意思決定者の不安に先回り（必要なとき）

• 完成した提案文書はコードブロックで出力する。 チャットのコピーボタンで1クリックでコピーでき、そのまま貼り付けられる
• 出力する提案文書では太字（**）などのmarkdown装飾を使わない。 貼り付け先で崩れるため、プレーンな文章にする
• 見出し名は提案内容に合わせて調整してよい（◎の枠組み「事実→理由→選択肢→リスク」は保つ）
• ◎ 配下が1項目だけなら、見出しを使わず本文に含める
• 模範解答例 → references/examples.md

品質チェック

出力する前に、提案文書がチェックリストを満たすか確認する。満たさない項目は直してから出力する。

→ references/output-quality.md