initial commit

README.md

@@ -0,0 +1,58 @@
+# Writing Proposals
+
+「◯◯を変えたい」というざっくりした思いつきから、AIが対話で材料を引き出し、相手に刺さる提案文書を作ってくれるスキルです。
+
+意思決定者に「それで！」と言わせる、結論ファーストの提案文に仕上がります。
+
+## 何ができるか
+
+- AIが提案に必要な材料（誰に・相手の問い・何を言い切るか・根拠）を1問ずつ質問してくれる
+- 「どうしますか？」ではなく「◯◯がおすすめ、理由はこう」と推奨案つきで聞いてくる
+- 材料が揃うと、結論ファーストで構造化された提案文書を出力してくれる
+- 過去に書いた文章を渡すと、あなたの文体に寄せてくれる（任意）
+
+テンプレートを機械的に埋めるのではなく、**書く前に「上流」（誰に・何を・なぜ）を整える**ことに専念します。
+
+## 使い方
+
+Cursor のチャット欄に、提案したいことを書いて以下のように依頼するだけです。
+
+```
+定例会議を減らす提案を作って
+```
+
+または
+
+```
+◯◯を提案したい
+```
+
+```
+提案書を書いて
+```
+
+AIが1問ずつ質問してくるので、答えていけば提案文書ができあがります。最初にわかっている情報はまとめて渡してもOKです。
+
+## こんなときに使う
+
+- 上司やチームに何かを提案したいが、どう書けば通るか分からないとき
+- AIに丸投げすると「当たり障りのない薄い文章」しか出てこないとき
+- 自分の作ったツールや改善案を、決裁権を持つ人に通したいとき
+- 提案の根拠をどう組み立てればいいか迷うとき
+
+## フォルダの中身
+
+```
+writing-proposals/
+├── README.md              ← この説明書
+├── SKILL.md               ← スキル本体（AIへの指示書）
+└── references/
+    ├── examples.md        ← 提案文書の模範例
+    └── output-quality.md  ← 出力品質チェックリスト
+```
+
+`SKILL.md` がスキル本体（AIへの指示書）で、`references/` の模範例・品質チェックリストを参照します。
+
+## 困ったとき
+
+何が起きても、まずはチャット欄でAIに状況を伝えてください。AIがエラーの内容を読み取り、次にやるべきことを教えてくれます。

SKILL.md

@@ -0,0 +1,105 @@
+---
+name: writing-proposals
+description: 誰かに何かを提案したいとき、対話で材料を引き出し、結論ファーストで意思決定者に刺さる提案文書を作るスキル。「提案文を作って」「提案書を書いて」「◯◯を提案したい」「提案を通したい」「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/examples.md)
+
+## 品質チェック
+
+出力する前に、提案文書がチェックリストを満たすか確認する。満たさない項目は直してから出力する。
+
+→ [references/output-quality.md](references/output-quality.md)

references/examples.md

@@ -0,0 +1,133 @@
+# 提案文書の模範例
+
+意思決定者の問いに、結論ファーストで答える提案文書の例。
+
+## 目次
+
+- 対話の流れ（例）
+- 例0：Before / After（上流を埋める効果）
+- メンツを守る言い換え（NG / OK）
+- 例1：在宅勤務を週2日に増やす
+- 例2：採用管理ツールの導入（他ツール比較あり）
+- 例3：ノー残業デーの導入
+
+---
+
+## 対話の流れ（例）
+
+ユーザーが雑に投げ、AIが1問ずつ推奨案つきで材料を引き出す。
+
+> ユーザー：定例会議を減らしたい
+> AI：①は「定例会議を減らす」ですね。②決めるのは誰ですか？ チームの定例なら直属の部長が承認者になりがちです。これでいいですか？
+> ユーザー：部長です
+> AI：③部長の頭の中の問いは「どの会議か／何がよくなるか／自分は何をすればいいか」が刺さります。この3つに答える形でOKですか？
+> ユーザー：OK
+> AI：④根拠になる数字はありますか？（なければ体験談でも可）
+> ユーザー：週7本・12時間、直近は7人中2人しか発言していない
+> AI：十分です。提案文書を作ります。
+
+材料が揃うと、下の「例0：After」のような文書が出力される。
+
+## 例0：Before / After（上流を埋める効果）
+
+同じ「定例会議を減らしたい」でも、上流（誰に・相手の問い・何を言い切るか）を埋めるかどうかで結果が変わる。
+
+**Before（AIに丸投げ・上流が空っぽ）**
+
+```
+お疲れ様です。会議運営の効率化についてご提案がございます。
+最近、会議時間の増加が生産性低下の要因として指摘されています。
+つきましては、定例会議の頻度の見直しをご検討いただけますと幸いです。
+```
+
+丁寧だが、どの会議か・何がよくなるか・何をしてほしいかに答えていない。意思決定者は「それで？」となる。
+
+**After（上流を埋めてから書く）**
+
+```
+【提案】報告だけの定例会議3本を隔週にして、浮いた月6時間を提案準備に充てます。ご承認をお願いします。
+
+◎ 現状の課題
+定例会議は週7本・延べ12時間。うち報告だけの3本が週3時間を占める。
+直近の会議では発言者が7人中2人だった。
+
+◎ 提案する理由
+報告だけの会議は資料の前日共有で代替できる。議論のある会議は残す。
+
+◎ リスクと対策
+共有漏れを防ぐため、資料は前日17:00までに投稿するルールにする。
+```
+
+## メンツを守る言い換え（NG / OK）
+
+同じ提案でも、過去を否定する書き方は通りにくい。状況の変化として語り、相手の功績を立てる。
+
+**NG（過去を否定）**
+
+```
+今の定例会議は無駄が多く非効率です。やめるべきです。
+```
+
+**OK（状況変化＋功績を立てる）**
+
+```
+定例会議は立ち上げ期に足並みを揃えるのに役立ってきました。
+人数も増えて自律的に動ける今、形を変えるタイミングだと思います。
+まず1ヶ月、報告は資料共有に切り替えて試させてください。
+```
+
+## 例1：在宅勤務を週2日に増やす
+
+```
+【提案】在宅勤務を週2日に増やすことを承認してください。来月から3か月の試験運用にしたいです。
+
+◎ 現状の課題
+通勤に往復2時間かかり、集中して作業する時間を確保しにくい。
+資料作成は1人で進める作業が多く、出社の必要性が低い。
+
+◎ 提案する理由
+移動時間を作業に充てられ、締め切り前の残業を減らせる。
+週2日に絞れば、対面が必要な会議や相談は出社日にまとめられる。
+
+◎ リスクと対策
+連携が滞らないよう、出社日を火・木に固定してチームで揃える。
+3か月後に稼働と成果を振り返り、継続するか判断する。
+```
+
+## 例2：採用管理ツールの導入（他ツール比較あり）
+
+```
+【提案】採用管理ツールをHRtable（月額3万円）で導入したいです。
+Googleスプレッドシートで管理している採用フローを移行する承認をお願いします。
+
+◎ 現状の課題
+選考状況の共有にメール往復が発生し、1件あたり平均30分かかっている。
+スプレッドシートの更新漏れで、面接の重複が月2〜3件発生している。
+
+◎ 他ツールとの比較検討
+・HRtable（月額3万円）— 採用サイトとAPI連携できる
+・Recruit Board（月額2万円）— API連携できないため見送り
+→推奨：HRtable（連携で更新漏れと面接重複を防げる）
+
+◎ コスト対効果
+月額3万円に対し、現在の対応工数（月約20時間）を半減できる見込み。
+```
+
+## 例3：ノー残業デーの導入
+
+```
+【提案】毎週水曜日をノー残業デーにしたいです。
+定時の18時退勤を原則とすることを承認していただきたいです。
+
+◎ 現状の課題
+・定時以降は集中力が落ち、同じ作業でも時間がかかる
+・平均残業時間は月40時間で、その時間帯の生産性は低い
+
+◎ 提案する理由
+・終わり時間を逆算することで生産性が上がる
+・残業の常態化を防ぐことで離職リスクを下げられる
+・週1回から始めることでまず効果を検証できる
+
+◎ 補足
+急ぎの仕事が入った場合は例外を認め、翌日に繰り越すルールとする。
+```

references/output-quality.md

@@ -0,0 +1,27 @@
+# 出力品質チェックリスト
+
+提案文書を出力する前に、以下を満たすか確認する。満たさない項目があれば直してから出力する。
+
+## 結論と構造
+
+- [ ] 1行目が結論（＝相手へのお願い）になっている。要約で終わらず「だから何をしてほしいか」まで言い切っている
+- [ ] 全体像 → 詳細の順になっている
+- [ ] 事実・解釈・提案が混ざらず分かれている
+- [ ] 情報が階層構造（◎ → ・）で整理され、同じ階層に同じ粒度の情報だけが入っている
+- [ ] 選択肢を示す場合、主要な案を網羅したうえで推奨案を明示している
+
+## 簡潔さと明確さ
+
+- [ ] 「〜について」「〜の件」で逃げず、具体的なお願いになっている
+- [ ] 一文が長すぎない（一文一義）。ただし削りすぎて意味が抜けていない
+- [ ] 「品質」「早急に」など解釈の分かれる言葉に具体的な定義がある
+- [ ] 同じ意味の言葉の表記揺れがない（用語が一貫している）
+- [ ] 過剰な敬語で冗長になっていない
+- [ ] 重要な数値や根拠が本文に書かれている（リンク頼みにしない）
+
+## 仕上げ
+
+- [ ] 箇条書きはMECE（漏れなく重複なく）で、語尾が統一されている
+- [ ] 期限があるなら日時まで具体的（例：2026/07/01 17:00）。「予定」ではなく確定表現になっている
+- [ ] 要点が1つだけの短い内容を、無理に階層化していない
+- [ ] 意味の区切りで改行され、視覚的に読みやすい