presentation-zen-garr-reynolds

name	presentation-zen-garr-reynolds
description	ガー・レイノルズのPresentation Zen原則でプレゼンを計画、設計、批評、修正する。聞き手中心のメッセージ、抑制、簡潔さ、自然さ、視覚的スライド、slideument分離、発表時の存在感を扱う。トーク作成、スライド構成、スピーカーノート、視覚設計指針、チェックリスト作成時に使う。汎用グラフィックデザイン、網羅的な学術引用レビュー、法務・規制文書、ライブ発表を前提にしない単体文書には使わない。

Presentation Zen Garr Reynolds

手順

Step 1: プレゼン作業の種類を分類する

1. 依頼された成果物を特定する。該当する種類は、トーク計画、スライド構成、レビュー、書き換え、スピーカーノート、配布資料分離、デリバリー指導である。
2. 成果物がライブ発表を対象にしているか確認する。単体記事、メモ、法務文書、学術的な引用レビューが主目的なら、このスキルを使わず、執筆、調査、法務、引用確認のワークフローを使う。
3. 作業を進められない情報だけを質問する。必要最小限の確認項目は、聞き手、発表時間、目的、会場、スライド枚数、元資料、必要形式である。

Step 2: 聞き手中心のブリーフを作る

1. 聞き手、聞き手の前提知識、発表後に起こしたい変化、聞き手に一つだけ覚えてほしい文を抽出または作成する。
2. 構造化されたブリーフや計画成果物が求められた場合は、assets/presentation-brief-template.md を使う。
3. ブリーフはスライド構成と分けて扱う。これは投影する本文ではなく、計画用の足場である。

Step 3: Presentation Zenの三原則を適用する

1. 抑制を適用する。中心メッセージを支えない論点、視覚要素、言葉、装飾を削る。
2. 簡潔さを適用する。ニュアンスを残しながら、見えるスライドの意味を明快、直接的、短時間で理解できる形にする。
3. 自然さを適用する。発表者が画面を読み上げるのではなく、聞き手に向かって話せるようにスライドとノートを整える。
4. 準備、スライド設計、ストーリー、デリバリー、注意点の詳しい基準が必要な場合は、references/principles.md を読む。

Step 4: スライドと文書を分離する

1. slideumentリスクを特定する。該当する兆候は、長い段落、長い箇条書き、小さすぎる注意書き、脚注だらけの画面、単体資料として読ませようとするスライドである。
2. 内容を、投影スライド、スピーカーノート、配布資料、付録、フォローアップ文書に分ける。
3. 投影スライドは視覚的で疎に保つ。正確性のために必要な検証詳細、引用、定義、手順の深さは、配布資料または付録へ移す。

Step 5: スライドの流れを設計する

1. フックから始める。使える型は、問い、緊張、具体的な場面、意外な観察、問題提起である。
2. 文脈、緊張、根拠または説明、解決、次の行動という明確な構造を作る。
3. 1枚または1ビートにつき、焦点を1つにする。
4. 箇条書きの多い文章より、大きなビジュアル、図、チャート、キーワード、短い主張文を優先する。
5. チャートには restrain / reduce / emphasize を適用する。チャートジャンクを取り除き、非本質的な線や印を減らし、伝えたい点を強調する。
6. 後ろの席から見えるように設計する。大きな文字、強いコントラスト、限定された色、十分な余白を使う。

Step 6: 成果物を作成または修正する

1. 新しいトークを作る場合は、ブリーフ、スライドごとの構成、スピーカーノートの意図、配布資料または付録の推奨を出す。
2. レビューの場合は、指摘を FATAL、MAJOR、MINOR に分類し、それぞれを抑制、簡潔さ、自然さ、slideument分離、ストーリー、視覚設計、デリバリーのいずれかに対応づける。
3. 書き換えの場合は、修正版の構成またはスライド文言を先に提示し、その後で削除または移動した内容を要約する。
4. デリバリー指導の場合は、冒頭、つなぎ、ペース、聞き手との接点、締め方を具体的に示す。

Step 7: Markdownドラフトがある場合は決定的チェックを実行する

1. ローカルのMarkdown構成案またはスライド下書きをレビューする場合は、python scripts/audit-presentation.py path/to/draft.md を実行する。
2. MAJORの指摘は、解消するか、理由を明示して受け入れる。
3. MINORの指摘は、圧縮、配布資料への分離、スライド分割の手がかりとして扱う。
4. ユーザーが検証を求めた場合、または下書きを監査済みと主張する場合は、コマンド出力を報告する。

エラーハンドリング

• 必要な文脈が不足し、推測できない場合は、聞き手、発表時間、目的、現行資料という最小限の情報だけを質問する。
• 元資料が投影スライドには密すぎる場合は、正確性に必要な内容を削除せず、スライドと配布資料に分ける。
• 法務、医療、規制、科学上の精度が必要な場合は、正確な主張をノートまたは付録に残し、見えるスライドを過度に圧縮しない。
• scripts/audit-presentation.py がファイルパス欠落で失敗した場合は、検証済みと主張する前に正しいMarkdownファイルを依頼または特定する。
• 引用や文献レビューが求められた場合は、先に調査ワークフローを使う。その後、発表形式を整える段階でのみこのスキルを適用する。