initial commit
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
commit
295c8f21ce
69
README.md
Normal file
69
README.md
Normal file
@ -0,0 +1,69 @@
|
||||
# Writing Presentations
|
||||
|
||||
通したい企画や発表を、会議・プレゼンといった「尺のある場」で通すための読み上げ原稿を、AIとの対話で作るスキルです。
|
||||
|
||||
AIが1問ずつインタビューして、あなたの中にしかない具体(実際に見た場面・心の声・正直な気持ち・そもそもなぜやりたいのか)を引き出し、聞き手の心が動くプレゼン原稿に仕上げます。
|
||||
|
||||
## 何ができるか
|
||||
|
||||
- AIが「実際に見た場面は?」「その時どう思った?」「なぜやりたいの?」と1問ずつ聞いてくれる
|
||||
- 固定の質問リストではなく、あなたの回答を踏まえて次の質問が変わる
|
||||
- 引き出した具体を、結論ファーストを保ったまま「問いを開いて、絵で閉じる」構成の原稿に組んでくれる
|
||||
- 完成した原稿はMarkdownファイルとして保存される
|
||||
|
||||
AIに丸投げして心が動くプレゼンは作れません。心を動かす具体はあなたの中にしかないからです。このスキルは、AIが作れないものをAIに引き出させる道具です。
|
||||
|
||||
## 提案スキル(writing-proposals)との関係
|
||||
|
||||
第9回講義で配布された提案スキル(writing-proposals)と組み合わせて使うことを前提としています。
|
||||
|
||||
- **提案スキル**:外を掘る(相手は誰か・相手の問いは何か・根拠は何か)→ 頭でわかる提案文書を作る
|
||||
- **プレゼンスキル**:自分を掘る(見た場面・感じたこと・弱さ・原体験)→ 心が動くプレゼン原稿に磨く
|
||||
|
||||
提案を通すプレゼンなら、先に提案スキルで提案文書を作ってから、このスキルに渡してください。
|
||||
|
||||
## 使い方
|
||||
|
||||
Cursorのチャット欄で、こう依頼するだけです。
|
||||
|
||||
```
|
||||
この提案を、会議で発表するプレゼンにしたい
|
||||
```
|
||||
|
||||
または
|
||||
|
||||
```
|
||||
プレゼンを作って
|
||||
```
|
||||
|
||||
```
|
||||
発表原稿を書いて
|
||||
```
|
||||
|
||||
AIが1問ずつ質問してくるので、答えていけばプレゼン原稿ができあがります。提案文書などの元原稿があれば、最初に渡してください。
|
||||
|
||||
## こんなときに使う
|
||||
|
||||
- 会議やプレゼンで、自分の企画を発表して通したいとき
|
||||
- 提案文書はできたが、発表すると「正しいのに、心が動かない」となりそうなとき
|
||||
- 卒業制作など、自分の作ったものの価値を発表で伝えたいとき
|
||||
- 話に自分のエピソードを入れたいが、何を話せばいいか自分でも言葉にできていないとき
|
||||
|
||||
## フォルダの中身
|
||||
|
||||
```
|
||||
writing-presentations/
|
||||
├── README.md ← この説明書
|
||||
├── SKILL.md ← スキル本体(AIへの指示書)
|
||||
└── references/
|
||||
├── examples.md ← 対話と原稿の模範例
|
||||
└── output-quality.md ← 出力品質チェックリスト
|
||||
```
|
||||
|
||||
`SKILL.md` がスキル本体(AIへの指示書)で、`references/` の模範例・品質チェックリストを参照します。
|
||||
|
||||
`SKILL.md` の下部には「チューニング欄」があります。自分の話し方・職場でよくあるプレゼンの場面・使わない表現・過去に話した内容を書き足すほど、あなた専用の型に育っていきます。
|
||||
|
||||
## 困ったとき
|
||||
|
||||
何が起きても、まずはチャット欄でAIに状況を伝えてください。AIがエラーの内容を読み取り、次にやるべきことを教えてくれます。
|
||||
135
SKILL.md
Normal file
135
SKILL.md
Normal file
@ -0,0 +1,135 @@
|
||||
---
|
||||
name: writing-presentations
|
||||
description: 通したい企画や発表を、会議・プレゼンなど「尺のある場」で通す読み上げ原稿を作るスキル。対話で本人の中にある具体(実際に見た場面・心の声・弱さ・原体験)を1問ずつ引き出し、結論ファーストを保ったまま「問いを開いて、絵で閉じる」構成に仕上げる。「プレゼンを作って」「発表原稿を書いて」「プレゼンの原稿を作りたい」「発表の準備をしたい」「writing-presentations」と依頼された際に使用する。
|
||||
---
|
||||
|
||||
# Writing Presentations
|
||||
|
||||
結論と中身が固まった元原稿(提案文書など)を、聞き手の心が動くプレゼンの読み上げ原稿に仕上げる。AIが説明を書くのではなく、**ユーザーの中にしかない具体を対話で引き出し、それを原稿に組む**ことに専念する。
|
||||
|
||||
## 大原則:説明するな、体験させろ
|
||||
|
||||
人を動かすのは説明ではなく、聞き手の頭に浮かぶ「絵」。
|
||||
|
||||
- 説明「定例会議は非効率で、時間が無駄になっています」→ 頭には届くが、心は動かない
|
||||
- 絵「先週の定例、30分のうち25分が、資料の読み上げでした。7人いて、口を開いたのは、2人だけだったんです」→ 場面が浮かび、聞き手が自分で「それは問題だ」と頷く
|
||||
|
||||
AIは世界中の文章の平均から書くため、放っておくと誰にでも当てはまる「説明」に寄る。心を動かす具体はユーザーの中にしかない。だからこのスキルは、書く前にユーザーを掘る。
|
||||
|
||||
## 前提:結論と中身が先、心を動かすのは後
|
||||
|
||||
このスキルは、ビジネスライティングとして成立した元原稿(結論・根拠・数字)に、心を動かす要素を足すためのもの。
|
||||
|
||||
- 提案を通すプレゼンで元原稿がない場合 → 先に提案スキル(writing-proposals)で提案文書を作るよう案内する
|
||||
- 提案以外(卒業制作の発表・報告など)の場合 → 「何を言い切るか(結論)」と「根拠」を最初の対話で固めてから進む
|
||||
|
||||
## 基本ルール
|
||||
|
||||
- **1問ずつ聞く。** まとめて質問攻めにしない
|
||||
- **固定の質問リストを上から埋めない。** ユーザーの回答を踏まえて、次に掘る場所を変える。回答に場面の気配があれば場面を深掘りし、抽象語(非効率・重要・課題・改善)が出たら、その裏の具体的な場面に戻す
|
||||
- **答えに詰まる質問には呼び水を添える。** 大きな質問を「それは何曜日の、何時ごろですか?」のような思い出しやすい小さな質問に割る
|
||||
- **選択肢が役立つ質問は選べる質問ツールで聞く**(場・TPO・たとえの案の選択など)。エピソードを掘る質問は自由に語ってもらう
|
||||
- **ユーザーは最初にまとめて渡してよい。** 元原稿や材料から分かることは聞かず、足りない分だけ掘る
|
||||
- **エピソードを創作しない。** 原稿に使う具体は、ユーザーが語った本当にあったことだけ。AIが場面・数字・感情をでっちあげない。盛らない(賭け金と回収の粒度を合わせる)
|
||||
- **ユーザーを否定せず、肯定的な言葉で伴走する**
|
||||
- **手で直させない。** 材料が揃ってから一度に出力し、修正は具体を足して出し直す
|
||||
- **出し直しのたびに、渡された具体が生きているか見張る。** AIは放っておくと、ユーザーの具体を平均的な説明に均してしまう。ユーザーの言葉・場面が消えかけていたら戻す
|
||||
|
||||
## 引き出す材料(インタビューの中心)
|
||||
|
||||
元原稿から流用できるもの(結論・根拠・数字)は聞き直さない。足りないものだけを掘る。
|
||||
|
||||
絵を浮かばせる材料には強さの順番がある:**①自分が実際に見た場面(最強・AIには作れない)→ ②聞き手に身近なたとえ → ③数字・データ(土台として必須だが、それだけでは絵にならない)**。まず①を探し、なければ②で補い、③で支える。
|
||||
|
||||
| # | 聞くこと | 役割 |
|
||||
|---|---|---|
|
||||
| ① | 誰に、どんな場で、何分話すか | 波の設計・TPO判断 |
|
||||
| ② | まだ言葉にできていない、実際に見た場面 | 最強の絵。スローモーションで具体化 |
|
||||
| ③ | その時の心の声(自分や周りは、どう思ったか) | 絵に感情を入れる |
|
||||
| ④ | 身近なたとえ | 体験がない部分の補完。AIが案を出し、ユーザーが選ぶ |
|
||||
| ⑤ | 弱さ・つまずいた瞬間・半信半疑だった正直な気持ち | 共感の入口(任意。堅い場では無理に出さない。ひと言でいい) |
|
||||
| ⑥ | そもそも、なぜこれをやりたいのか(Why・原体験) | 「どうなる」と締めを動かす |
|
||||
| ⑦ | 聞き手の頭に浮かぶ懸念点と、その答え | 気づかれる前に先出しして回収する材料 |
|
||||
|
||||
### 場面の掘り方(絵にする3つのコツ)
|
||||
|
||||
1. **超具体的にする**:場面をスローモーションで見る。「いつ・どこで」「周りに誰がいて、どんな顔だったか」を細かく
|
||||
2. **心の声を入れる**:「その時、心の中で何と言っていましたか?」
|
||||
3. **たとえる**:聞き手が知らないことは、知っていることに乗せる
|
||||
|
||||
たとえはAIが出してよい。ユーザーの体験の創作は禁止だが、みんなが知っている場面へのたとえはAIの得意技。「この困りを、誰でも知っている場面にたとえると?」の案を複数出し、聞き手にいちばん近いものをユーザーに選んでもらう。
|
||||
|
||||
## 進め方
|
||||
|
||||
1. **受け取る**:元原稿を読み、6ステップ構成(下記)に仮マッピングする。結論・根拠・数字は元原稿から流用し、足りないもの(絵・弱さ・フック・懸念点)を特定する
|
||||
2. **掘る**:足りない材料を1問ずつ引き出す(「引き出す材料」参照)
|
||||
3. **出力する**:6ステップの読み上げ原稿を生成し、Markdownファイルとして保存する
|
||||
4. **品質チェック**:チェックリストで確認してから渡す(「品質チェック」参照)
|
||||
|
||||
ユーザーが「もう十分」と言えば、その時点で出力に進む。
|
||||
|
||||
## 原稿の構成(6ステップ)
|
||||
|
||||
引き出した具体を、この弧に流して読み上げ原稿にする。
|
||||
|
||||
```
|
||||
① フック 絵か問いで、つかむ(15〜30秒)
|
||||
② 結論 何を提案するか、一言で
|
||||
③ なぜ 今の困りを、絵で見せる + 放置すると何を失うか(賭け金)
|
||||
④ どうやって やり方を、短く
|
||||
⑤ どうなる 変わった未来を、絵で見せる(原体験・Whyをここか締めで回収)
|
||||
⑥ お願い 承認してほしいことを、はっきり
|
||||
```
|
||||
|
||||
構成の判断基準:
|
||||
|
||||
- **興味 = 知りたい − いま知っている。** この差には「悪い差」(何の話かわからない不安 → 離脱)と「良い差」(続きが気になる → 前のめり)がある
|
||||
- **結論は隠さない。** 隠すと悪い差になる。結論を先に渡すと悪い差が閉じ、「本当に効く?どれだけ変わる?」という良い差が開く。引っ張るのは結論の先だけ
|
||||
- **良い差を開く道具は3つ**:問いかける(乱用注意)/チラ見せする(結論は渡した上で、中身の答えを焦らす)/賭け金を上げる(放置すると何を失うかを具体化。定位置は③なぜ)
|
||||
- **開いた差は、絵で閉じる**
|
||||
- **絵は結論の代わりではなく、根拠。** 絵だけ並べると「で、何が言いたいの」の作文になる。どちらかを残すなら結論
|
||||
- **波は短く刻む。** 問いを開いたら数十秒〜長くて1、2分で絵で回収する。仕事のプレゼンは、体は帰れないが心は一瞬で離れる場。映画型(最後まで伏せる)にしない
|
||||
- **山場の絵は1つに絞る。** 全部を山にすると、全部が平らになる
|
||||
- **懸念点は先出しする。** 聞き手の頭に浮かぶ懸念・突っ込みどころを、気づかれる前にこちらから伝えて答える
|
||||
- **引っ張りは、注意の前借り。** 見合う絵で返せない引っ張りは「釣り」になり、次から話を聞いてもらえなくなる
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
- 話し言葉の読み上げ原稿として書く。書き言葉や体言止めの連続にせず、ユーザーの話し方・語彙に寄せる(チューニング欄参照)
|
||||
- 尺に合わせて分量を設計する(目安:話し言葉で1分あたり300字前後)
|
||||
- Markdownファイルとして保存する(例:`プレゼン原稿_定例会議.md`)。構成ラベルは見出し、読み上げ本文は地の文で書く。ファイルを保存できない環境では、コードブロックで出力する
|
||||
- 模範例 → [references/examples.md](references/examples.md)
|
||||
|
||||
## 品質チェック
|
||||
|
||||
出力する前に、原稿がチェックリストを満たすか確認する。満たさない項目は直してから出力する。
|
||||
|
||||
→ [references/output-quality.md](references/output-quality.md)
|
||||
|
||||
## やらないこと
|
||||
|
||||
- エピソード・体験談の創作(本人の中にあるものだけを使う)
|
||||
- スライド資料(ビジュアル)の生成。作るのは原稿=話の中身まで
|
||||
- 提案文書そのものの作成(提案スキルの責任範囲)
|
||||
- 元原稿のビジネスライティングとしての品質担保(入力時点で成立している前提)
|
||||
- 出力後にサブエージェントレビューを自動実行したり、先回りして案内したりすること(ユーザーが自分で頼む体験として残す)
|
||||
|
||||
## チューニング欄(あなた専用に育てる)
|
||||
|
||||
このスキルは完璧ではない。使いながら以下を書き足して、自分専用の型に育てる。
|
||||
|
||||
### 自分の話し方
|
||||
|
||||
(例:「〜なんです」で柔らかく話す/短い文でテンポよく)
|
||||
|
||||
### 職場でよくあるプレゼンの場面
|
||||
|
||||
(例:月曜朝の部会で10分/役員への四半期報告で15分)
|
||||
|
||||
### 使わない表現
|
||||
|
||||
(例:カタカナのビジネス用語/過度な煽り文句)
|
||||
|
||||
### 過去に話した内容
|
||||
|
||||
(結果が良かったプレゼンやスピーチの原稿・メモを貼る。出来栄えではなく、相手が動いたかで選ぶ)
|
||||
98
references/examples.md
Normal file
98
references/examples.md
Normal file
@ -0,0 +1,98 @@
|
||||
# プレゼン原稿の模範例
|
||||
|
||||
「定例会議を減らす」を題材に、対話で具体を引き出し、心が動く原稿に変わるまでの一周。会議の議題の1つとして話す、約2分の短いプレゼンの例(数十秒でも、自分の意見を伝えて通す場面はプレゼンに含む)。
|
||||
|
||||
## 目次
|
||||
|
||||
- 元原稿(説明だけの発表)
|
||||
- 対話の流れ(例)
|
||||
- 完成した原稿(具体を渡した後)
|
||||
- 何が変わったか(Before / After の対応表)
|
||||
- たとえをAIが出す(体験がない場合の例)
|
||||
|
||||
---
|
||||
|
||||
## 元原稿(説明だけの発表)
|
||||
|
||||
提案スキルで作った、ビジネスライティングとしては十分な発表原稿。結論も先、数字の根拠もある。だが心は動かない。
|
||||
|
||||
```
|
||||
定例会議の進め方について、提案があります。
|
||||
結論から言います。報告中心の定例3本を、隔週の開催に、変えたいです。
|
||||
いまの定例は週7本、あわせて週12時間。
|
||||
うち、報告だけの3本が、週3時間を占めています。
|
||||
隔週にすれば、月に6時間、年で約70時間が空きます。
|
||||
報告は、前日に資料を共有すれば、読み上げなくても回ります。
|
||||
まず、この3本から、隔週に。ご承認いただけないでしょうか。
|
||||
```
|
||||
|
||||
全部正しい。だが全部「説明」で、どこの会社にも貼れる=誰のプレゼンでもない。ここに足りないのは、絵・賭け金・弱さ・原体験。
|
||||
|
||||
## 対話の流れ(例)
|
||||
|
||||
元原稿から結論・数字は流用できるので聞き直さない。足りない具体だけを1問ずつ掘る。
|
||||
|
||||
> AI:この提案、誰に、どんな場で、何分くらい話しますか? 定例の見直しなら、週次の全体会議で、議題の1つとして話す形が多いですが、どうでしょう?
|
||||
> ユーザー:そうです。会議のみんなの前で、議題の1つとして。2分くらいです
|
||||
> AI:2分ですね。問いを開いて絵で閉じる波は1〜2回、山場の絵は1つに絞ります。今の困りで、実際に見た場面はありますか? 直近の定例を、スローモーションで思い出してみてください
|
||||
> ユーザー:先週の定例。30分のうち、25分が資料の読み上げ。7人いて、口を開いたのは、2人だけでした
|
||||
> AI:その場面、強い絵になります。このまま何もしなければ、何を失いますか?
|
||||
> ユーザー:報告を聞くだけの時間が、年150時間。1ヶ月分です
|
||||
> AI:あなた自身の、正直な気持ちはどうでしたか? 半信半疑だったこと、当たり前だと思っていたことがあれば
|
||||
> ユーザー:私も長いこと、この会議を当たり前だと思って、疑うことすらなかった。先週、ふと周りを見たら、全員が同じ顔をしていて
|
||||
> AI:そもそも、なぜ変えたいと思ったんですか?
|
||||
> ユーザー:その時間で、本当はやりたい仕事が、あったからです
|
||||
> AI:材料が揃いました。原稿を作ります
|
||||
|
||||
## 完成した原稿(具体を渡した後)
|
||||
|
||||
```
|
||||
先週の定例会議。30分のうち、25分が、資料の読み上げでした。
|
||||
7人いて、口を開いたのは、2人。
|
||||
──報告だけの定例3本を、隔週にしませんか。
|
||||
あの読み上げを聞くだけの時間が、1年で150時間。
|
||||
まるまる1ヶ月分が、毎年、消えています。
|
||||
正直に言うと、私も長い間、この会議を当たり前だと思って、
|
||||
疑うことすら、ありませんでした。でも先週、ふと周りを見て、
|
||||
全員が同じ顔をしているのに、気づいたんです。
|
||||
やり方は、シンプルです。報告の3本を隔週にして、
|
||||
資料は前日に共有する。それだけ。
|
||||
それだけで、年に70時間ちかく──消えた時間の半分が、戻ります。
|
||||
ずっと後回しにしてきた、やりたかった仕事に、手がつけられます。
|
||||
まず、報告の3本だけ。1ヶ月、試させてもらえませんか。
|
||||
```
|
||||
|
||||
## 何が変わったか(Before / After の対応表)
|
||||
|
||||
企画の中身は同じ(定例3本を隔週に)。変わったのは、渡した具体だけ。
|
||||
|
||||
| 6ステップ | 元原稿 | 完成した原稿 |
|
||||
|---|---|---|
|
||||
| ① フック | なし(いきなり本題) | 沈黙の場面の絵(7人中2人) |
|
||||
| ② 結論 | 先にある | 先にある(維持) |
|
||||
| ③ なぜ | 数字のみ | 絵 + 賭け金(年150時間=1ヶ月分が消え続ける) |
|
||||
| ④ どうやって | ある | 短く維持 |
|
||||
| ⑤ どうなる | 数字のみ(年70時間) | 数字 + 原体験(やりたかった仕事に手がつく) |
|
||||
| ⑥ お願い | ある | 小さく・試しやすく(まず3本だけ、1ヶ月) |
|
||||
| 弱さ | なし | 「私も当たり前だと思っていた」(ひと言・穏やかに) |
|
||||
|
||||
注意点:
|
||||
|
||||
- 原稿に出てくる絵は、すべてユーザーがインタビューで渡したもの。AIが場面を足していない
|
||||
- 賭け金は150時間、回収は「半分=70時間」と正直に。盛っていない
|
||||
- 弱さは「内職していました」のような告白ではなく、堅い場でも出せる穏やかな自己開示にしている
|
||||
- 分量は約400字=渡された尺(2分)に収まる。尺が5分、10分と長い場合も6ステップは同じで、「問いを開いて、絵で閉じる」波の数を増やして分量を設計する。山場の絵は1つのまま増やさない
|
||||
|
||||
## たとえをAIが出す(体験がない場合の例)
|
||||
|
||||
自分が実際に見た場面がないときは、聞き手に身近なたとえで補う。たとえの案出しはAIの得意技。
|
||||
|
||||
> ユーザー:その現場には行ったことがなくて、見た場面がないんです
|
||||
> AI:では、身近なたとえで絵にしましょう。「会議の資料の読み上げを聞いている時間」を、誰でも知っている場面にたとえると、こんな案があります。
|
||||
> ・朝礼で、長い校長先生の話を聞いている時間
|
||||
> ・機内で、毎回同じ安全ビデオを見せられる時間
|
||||
> ・説明書を音読されるのを、隣で聞いている時間
|
||||
> 聞き手にいちばん近いのは、どれですか?
|
||||
> ユーザー:校長先生の話が、いちばん伝わりそう
|
||||
|
||||
選ぶのは必ずユーザー。聞き手を知っているのはユーザーだけ。
|
||||
34
references/output-quality.md
Normal file
34
references/output-quality.md
Normal file
@ -0,0 +1,34 @@
|
||||
# 出力品質チェックリスト
|
||||
|
||||
プレゼン原稿を出力する前に、以下を満たすか確認する。満たさない項目があれば直してから出力する。
|
||||
|
||||
## 結論と構成
|
||||
|
||||
- [ ] 結論(何を提案・主張するか)が冒頭近くにあり、隠されていない
|
||||
- [ ] フックが絵か問いで始まっている(一般論・自己紹介・前置きで始まっていない)
|
||||
- [ ] 「なぜ」に絵と賭け金(放置すると何を失うか)が入っている
|
||||
- [ ] 「どうなる」に変わった未来の絵が入っている
|
||||
- [ ] 最後のお願いが具体的で、聞き手が Yes / No を判断できる
|
||||
- [ ] 聞き手の懸念点を、気づかれる前に先出しして答えている
|
||||
|
||||
## 絵と具体
|
||||
|
||||
- [ ] 原稿の中の場面・数字・感情は、すべてユーザーが渡したもの(AIが創作した体験がない)
|
||||
- [ ] 抽象語(非効率・重要・課題・改善など)だけで押している箇所がない。裏の具体的な場面に戻している
|
||||
- [ ] 山場の絵が1つに絞られている(全部を山にしていない)
|
||||
- [ ] 絵が結論の根拠として置かれている(絵だけが並ぶ作文になっていない)
|
||||
- [ ] 弱さを入れる場合、ひと言で、場のTPOに合っている(堅い場で長々と失敗談を話していない)
|
||||
|
||||
## 興味の波
|
||||
|
||||
- [ ] 開いた問いが、すべて絵か答えで閉じられている(開きっぱなしの問いがない)
|
||||
- [ ] 1つの引っ張りが数十秒〜1、2分以内で回収されている(最後まで伏せる映画型になっていない)
|
||||
- [ ] 煽りすぎ・引っ張りすぎになっていない(引っ張りに見合う中身が返っている)
|
||||
- [ ] 賭け金と回収の粒度が合っている(実際より大きく見せて盛っていない)
|
||||
|
||||
## 話し言葉
|
||||
|
||||
- [ ] 声に出して読める話し言葉になっている(書き言葉・体言止めの連続になっていない)
|
||||
- [ ] ユーザーの話し方・語彙に寄っている(チューニング欄・過去に話した内容を反映)
|
||||
- [ ] 指定された尺に収まる分量になっている
|
||||
- [ ] 上から目線・偉そうな表現がない
|
||||
Loading…
Reference in New Issue
Block a user