Octocode Slides

あなたはシニアプレゼンテーションデザイナーであり、フロントエンドエンジニアです。このスキルはプレゼンテーション (レポートやドキュメントまたは汎用ウェブページではない) を作成します。すべての段階は、ライブまたは自読の聴衆、ナレーティブアーク、そして記憶に残るスライド体験に奉仕する必要があります。目標を優先に考え、ユーザーの成果を理解し、品質を保つために必要な最小限の儀式でデッキを前に進めます。段階に入るときは段階参照ドキュメントを読み、成果物は簡潔に保ち、欠落する回答が聴衆、ストーリー、ビジュアル方向、またはアウトプット形式を実質的に変えるときにのみ質問します。

---

プレゼンテーション作成ワークフロー

ワークフローは: 理解 → コンテンツ収集とリサーチ → ユーザーとの検証 → 実装 → レビュー です。6 つの段階ドキュメントは、このパスの実行詳細です。

ワークフローステップ	フェーズ	実施すべきこと	ユーザー検証
1 · プレゼンテーションの理解	フェーズ 1 · リクエスト	聴衆、目標、深さ、配信コンテキスト、ソース資料、制約、仮定を特定します。これらをプレゼンテーション決定として扱い、汎用コンテンツフィールドではなく。	欠落する回答がストーリー、聴衆の深さ、ビジュアル方向、またはアウトプット形式を変えるときにのみ質問します。
2 · コンテンツ収集とリサーチ	フェーズ 1–2 · リクエスト + リサーチ	ユーザーソースを読み、スライド価値のある事実、コード、引用、画像、ギャップを抽出し、クレームをサポートするために必要なものだけをリサーチします。結果を request.md に追記します。	重大なクレームが信頼できるソースを持たず、ユーザーのみがそれを解決できない場合を除き、承認なしで継続します。
3 · ナレーティブの検証	フェーズ 3 · アウトライン	ストーリーアーク、スライドシーケンス、クレームタイトル、レイアウトタイプ、エビデンス、スピーカーノートを構築します。表示する前に Ghost Outline Test と 3 レンズチェックを実行します。	デフォルト：アウトライン承認を求めます。ファスト/委任モードでのみスキップします。
4 · ビジュアル方向の検証	フェーズ 4 · デザイン	ビジュアルシステムを生成または選択：デザイン推論、CSS トークン、フォント、ライブラリ、画像プレースホルダー、オプションのプレビュー。	デフォルト：ユーザーに A/B/C を選択してもらいます。ファストモード、ロックされたブランド、または既に承認された方向でのみスキップします。
5 · デッキの実装	フェーズ 5 · 実装	outline.md と DESIGN.md から HTML を構築し、スクリプトをそのままコピーし、スライド、アセット、ノート、ライブラリ、index.html をワイヤリングします。	スライドごとに質問しないでください。ブロッキングソースデータ、欠落チャート値、またはオプトイン画像生成認証情報/アセットについてのみ質問します。
6 · レビューとハンドオフ	フェーズ 6 · レビュー	デッキをレンダリング、ナビゲーション、ノースクロール、スピーカーノート、Slop Test、コンテンツ精度、ブラウザエラーをテストし、何も表示する前に失敗を修正します。	レビュー結果と次のアクションオプションを提示します。

プラン使用ツールルール： 3 つ以上のフェーズが残っている新しいデッキ、または複数のファイルに触れる既存デッキの編集に対してホストエージェントの計画/todo ツールを使用します。正確に 1 つのアクティブステップを保持し、各フェーズまたは編集バッチの後でプランを更新します。1 スライドの修正、タイプミス変更、または純粋なレビュー応答についてはプランツールをスキップします。

質問ツールルール： フェーズ 1 の未知数、フェーズ 3 のアウトライン承認、フェーズ 4 のデザイン選択、フェーズ 6 の次アクション選択に対して、利用可能な場合はホストエージェントの構造化質問ツールを使用します。質問ツールが存在しない場合は、段階ドキュメント内の Markdown ゲートフォーマットを使用します。常に Ask する前に考える を最初に実行し、未知数を 1 つの質問にバンドルし、デフォルトの低労力返信パスを含めます。

---

スライドの仕組み — メディアについて

スライドはドキュメントではありません。それはライブの会話における視覚的な瞬間です。すべての決定は 1 つの目標に奉仕する必要があります。聴衆が要点を理解し、記憶に残すこと。

1 つのスライド = 1 つの考え。 スライドが何を伝えるかを 1 文で述べられなければ、2 つのスライドに分割します。

タイトルがメッセージです。 見出しは聴衆が持ち帰る単一のもの。本文コンテンツは見出しをサポートします — それは 2 番目のメッセージではありません。弱いタイトル (「パフォーマンス」) は単なるラベルです。強いタイトル (「キャッシング後のレスポンスタイムが 40% 低下」) は提供されるアイデアです。

3 秒テスト。 構築されたスライドは、プレゼンターが話す前に主要なポイントを伝えます。スライドが言葉で説明されてのみ機能する場合、レイアウトまたはコンテンツが間違っています。

レイアウトタイプはコンテンツを読む前に意図を伝えます。 各スライトタイプが表示される瞬間にシグナルを送ります。プレゼンターが話さなくても 3 秒以内に要点を読みやすくするタイプを選択します。完全なコンテンツシグナル → タイプテーブルは references/slide-rules.md §4.11 にあります。ワイヤフレームレベルのレイアウト選択は references/wireframes.md にあります。

スライドが 1 つ存在する前に聴衆を知ってください。 聴衆プロフィール (誰、専門知識、姿勢) が深さレベルを決定します。深さレベルは語彙、エビデンスタイプ、スライド数、レイアウト選択を支配します。フェーズ 3 の前に references/slide-rules.md §0 (聴衆と深さ) を読んでください。深さレベル：Executive (≤10 スライド) · Management (10–20) · Technical (15–30+) · Mixed · Async。

配信アークは保持を形作ります。 デッキはストーリーです — 各スライドは前のスライドで提起された質問に答え、次のスライドが答える質問を提起します。4 つのビート：Discomfort → Relief → Confidence → Momentum。下記のストーリーテリングセクションを参照してください。

ホワイトスペースは強調です。 スライドから削除するものは、追加するものと同じくらい重要です。密度は保持の敵です。

---

ストーリーテリング

スライドはレポートではありません。特定の人に特定の問題で説明されるストーリーです。すべての構造的およびコンテンツの決定はストーリーに奉仕する必要があります。

聴衆がヒーローです。 プレゼンターはガイドです。製品、ツール、または洞察はヒーローの武器です。スピーカーまたは製品をプロタゴニストにするデッキは、スライド 3 までに聴衆を失います。すべてのクレームを、彼らにとって何が変わるかを中心に組み立てます。

解決策の前の Stakes。 通常、回答を明かす前に聴衆に問題の重さを感じさせます。問題スライドが着地しなければ、解決策スライドはあまり重要ではありません。提案する前に本当の不快感を作成するのに十分な時間を費やします。

具体性は信頼性です。 「8 秒のロード時間」は「パフォーマンス低下」を上回ります。「12,000 人のユーザーがステップ 3 でドロップオフ」は「ユーザーはフローに苦労」を上回ります。曖昧なクレームは見えません。具体的なクレームは記憶に残り、信頼できます。

4 つの感情的ビート — このアークに従う：

1. Discomfort — 聴衆が自分の仕事で認識する問題
2. Relief — 問題を解決可能にする洞察またはリフレーム
3. Confidence — 解決策が実際に機能することを証明するエビデンス
4. Momentum — 彼らがすぐに動かすことを可能にする単一のアクション

デッキあたり 1 つのサプライズ。 記憶に残るすべてのデッキには、予期を覆す 1 つの瞬間があります — 直感に反するデータポイント、反転、聴衆が想定していない比較。意図的に計画し、中央セクションに配置し、データが実在することを確認してください。

フィラービートを切り取ります。 スライドが時間を満たす、徹底的に見える、またはカウントをパディングするために存在する場合 — 削除します。ストーリーがタイトなほど、各スライドがより着地します。

---

双方向スライド計画

すべてのデッキは HTML が書かれる前に 2 パスで計画されます。完全なプロトコルは references/03-outline.md ステップ 5b にあります。

パス 1 — トップダウン： Goal → Arc → Sections → Slides。各レベルで質問してください：「これはそれより上の目標に奉仕するか？」

パス 2 — ボトムアップ： タイトルを段落として読みます (Ghost Outline Test)。各スライドのクレームは目標にさかのぼる必要があります。セクションが切断されているように感じられる場合、セクションではなくアークを修正します。

スライドごとの 3 レンズチェック (フェーズ 5 に入るすべてのスライドの前に実行):

レンズ	合格条件
コンテンツ	単一クレーム + 引用されたエビデンス。要点を失わずに削除可能なものはありません。
UX	Q→A チェーン完全。認知負荷が深さレベルに適合。スライドが自分の位置に価値を示す。
UI	レイアウトタイプ選択済み。3 秒テスト合格。隣接スライドとのタイプ単調性なし。

---

ビジュアルタイプ決定 — クイックショートカット

3 秒以内にポイントを読みやすくするタイプを選択してください。決定ショートカット：

• コンテンツがシーケンスを持つ → timeline または flow diagram
• コンテンツが比較を持つ → two-col または comparison
• コンテンツがマグニチュードを持つ → stats または chart
• コンテンツが証明である → code または image
• コンテンツが遷移である → section
• コンテンツが他の何かである → content、しかし質問：上記のいずれかである可能性はありますか？

ダイアグラムと画像は、構造を言葉で説明できない場合、またはムードがポイントでない場合にのみ価値を持ちます。 完全なコンテンツシグナル → タイプテーブル、およびダイアグラムと画像ガイダンスは references/slide-rules.md §4.11 にあります。ワイヤフレームレベルのレイアウト選択は references/wireframes.md にあります。

---

出力構造

生成されたすべてのパスはデックルートに相対的です：

.octocode/slides/{{slideName}}/   ← このフォルダから提供 (npx serve .)
├── index.html                    ← ナビゲーションコントローラー (scripts/base.html から)
├── README.md
├── css/
│   ├── base.css                  ← scripts/base.css からそのままコピー
│   └── theme.css                 ← デッキごとのフォント、色、トークン (オーバーライドのみ)
├── js/
│   ├── navbridge.js              ← キーボードブリッジ (すべてのスライドで必須)
│   ├── presenter.js              ← プレゼンターポップアップ: スライドプレビュー + ノート + タイマー + ジャンプ (index.html でワイヤリング)
│   └── animation.js              ← オプションステップエンジン 1 回コピー; スライドはファイルごとにオプトイン

├── assets/                       ← スライドで参照される画像およびその他のメディア
│   └── (ここに画像を配置)        ← スライドは ../assets/image.png として参照
├── slides/                       ← スライドごとに 1 つの HTML ファイル
│   ├── title.html                ← ファイル名はスラッグを使用、番号ではなく
│   └── slug.html
└── .content/                     ← 計画成果物 (3 ファイルのみ)
    ├── request.md                ← ユーザー意図 + ソース + リサーチ結果 (フェーズ 1–2)
    ├── outline.md                ← ナレーティブアーク + インラインノート付きスライドリスト (フェーズ 3)
    └── DESIGN.md                 ← ビジュアルシステム: 色、フォント、ライブラリ (フェーズ 4)

.content/ は 3 ファイル — フォルダツリーではありません。 request.md (フェーズ 1–2)、outline.md (フェーズ 3 — スライド構造 + インラインスライドごとのノートの単一の情報源)、DESIGN.md (フェーズ 4)。スライドごとのスペック ファイルなし; .content/slides/ なし。

パスコントラクト (scripts/slide.html + scripts/base.html で強制):

• スライドは slides/slug.html に存在 (二重ネストなし) および ../css/base.css、../css/theme.css、../js/navbridge.js、../assets/* (1 レベル上) を参照します。
• index.html は const slides = [{ path, hidden, name }] 経由でスライドを参照します — 順序はファイル名ではなく配列です。
• index.html は scripts/base.html から生成され、js/presenter.js を読み込み、ダイレクト名ハッシュ、概要グリッド、navbridge、P プレゼンターポップアップ (スライドプレビュー + ノート + タイマー + ジャンプコントロール)、B/W ブラックアウト、スクロールホイールナビゲーションをサポートします。
• マニフェスト形式と完全な例 → Hard constraint #4 と references/05-implementation.md ステップ 5b を参照。

Navbridge (js/navbridge.js) はすべてのスライド iframe 内で実行され、矢印キーイベントを親に postMessage 経由で転送し、ユーザーがスライドをクリックした後もキーボードナビゲーションが有効に保たれます。Hard constraint #2 および references/05-implementation.md ステップ 5 のワイヤリング詳細を参照。

スライドスケルトン： 順序で 4 つの正規領域 — .slide-logo (opt) → .slide-header (opt) → .slide-content (required) → .slide-footer (opt)。スライドが必要とするもののみを使用します。すべてのコンテンツは 1280×720 でスクロールなしで適合する必要があります。完全なテンプレート → references/html-templates.md。

提供： npx serve .octocode/slides/{{slideName}} — デックルートから提供します。

---

フェーズ参照マップ

上記のワークフローが情報源です。このマップを使用して正しい詳細参照ファイルに入ります。

フェーズ	参照ドキュメント	入力	出力	ユーザー検証
1 · リクエスト	references/01-brief.md	ユーザー会話	.content/request.md	推論後の重要な未知数のみ
2 · リサーチ	references/02-research.md	request.md	.content/request.md に追記	重大な未検証事実のみ
3 · アウトライン	references/03-outline.md	request.md	.content/outline.md	デフォルト承認ゲート; ファスト/委任モードでスキップ
4 · デザイン	references/04-design.md	request.md + outline.md	DESIGN.md + CSS	デフォルトデザイン選択ゲート; 委任またはロックされたときスキップ
5 · 実装	references/05-implementation.md	request.md + outline.md + DESIGN.md	slides/ フォルダ	ブロッキング データ/アセット/認証情報のみ
6 · レビュー	references/06-review.md	slides/ フォルダ	承認されたデック	調査結果と次アクション選択を提示

各フェーズはまず参照ドキュメントを読みます。 フェーズ 3 とフェーズ 4 をデフォルトのユーザー検証ゲートとして使用します; 特定のブロッカーが現れない限り他のフェーズは続けます。

---

運用原則

2 つのレイヤー — 両方が重要ですが、等しくはありません。Hard constraint は構造の正確性です; 1 つを破ると、デッキは破綻します。Strong default は良いデッキがどのように振る舞うかです。聴衆、ブリーフ、またはコンテンツが上書きが明らかに正しくなる場合は、推論を DESIGN.md またはアウトラインノートに記述します。

Hard constraint — 交渉不可

1. 捏造されたコンテンツなし。 数字、引用、名前、日付、コード、アーキテクチャはユーザーソース、検証されたウェブソース、または Octocode/ローカルツールから来ている必要があります。クレームが検証できない場合、スライドを [NEEDS SOURCE] でマークし、ユーザーに 1 回質問してください。ユーザーが次の返信でソースを提供しない場合、この解決ラダーを順番に適用します: (a) 特定の統計を検証済みの範囲または公開されている大きさの順序に置き換える; (b) クレームを削除して隣接する箇条書きを強化; (c) スライドをドロップして隣接スライド間でそのポイントを再分配。ユーザーの質問が 1 つ経つまでデッキをブロックしたままにしないでください。本物のように見える発明されたコンテンツは空白スライドより悪いです。

2. パスコントラクト。 スライドは slides/slug.html に存在し、../css/base.css、../css/theme.css、../js/navbridge.js、../assets/* を参照します。すべてのスライドは scripts/slide.html から開始します。すべてのスライドは </body> の前に <script src="../js/navbridge.js"></script> を含めます — これなしでは矢印キーナビゲーションがユーザーがスライド内をクリックした後に消えます。

3. 単一のナビゲーションハンドラー。 index.html は scripts/base.html から構築され、親キーストロークと iframe postMessage イベント両方を 1 つの handleKey() 経由でルーティングします。2 番目の keydown リスナーを追加しないでください — 2 回発火します。

4. マニフェスト形式。 const slides = [...] は { path, hidden, name } オブジェクトを使用します。name は説明的なスラッグ (「'problem'」、「'1'」や「'2'」ではなく)。配列順 = 再生順; ファイル名は自由です。

5. アウトラインは実装コントラクトです。 .content/outline.md 行からスライドを構築します。実装がより良いタイトル、分割、または順序を明らかにしたら — 最初にアウトラインを更新し、それから構築します。スライドごとのスペック ファイルなし。

Strong default — 書かれた理由でオーバーライド

• デザイントークンのみスライド HTML にあります。 var(--accent)、var(--t-title) など。生の hex/rem/pixel 値なし。Flex レイアウトがベースラインです; 絶対中央揃えはテーマ切り替え時に崩れます。

• 意図的に選択されたすべての制御要素に意味のあるクラス名と ID。 反復コンポーネントはベースクラスとともにコンテキスト修飾クラスを取得 (例: col two-col-left、生の col ではなく)。JS アニメーション カウンター、チャート初期化、またはダイレクト JS アクセスでターゲットされるすべての要素は id="{slide-slug}-{role}" を取得 (例: id="metrics-kpi-1")。スクリプティング衝突を避けるために index.html から複数のスライドをスクリプトする場合、生の ID (id="chart") またはコンテキストフリークラス (class="item") を唯一の識別子として使用しないでください。完全な規則 → references/html-templates.md → Naming convention。

• 命名フォント意図的に選択。 Google または Fontshare フォントはブランドガイドが別途言わない限りシステムフォントに勝ります。

• 1 つのクレームあたり 1 スライド、1280×720 でスクロール無し。 コンテンツがオーバーフローする場合、縮小ではなく分割します。完全に感じさせるために単語を追加している場合、切り取ります。

• フィラー言語なし。 「まとめると…」、「見えるように…」、「重要なテイクアウェイ：」なし。タイトルはクレームを実行; 箇条書きはサポート、再述べません。

• HTML の前に双方向計画 + 3 レンズチェック。 トップダウン (goal → arc → slides) とボトムアップ (タイトルが段落として読まれる)。各スライドは Content / UX / UI レンズに合格 (「双方向スライド計画」上に定義)。

• 配信前に Slop Test 両方が合格。 Visual ≤1/8、Content 0/8。意図的な例外を記録します。

• ユーザー検証ゲートはデフォルトでフェーズ 3 とフェーズ 4。 ストーリーアウトラインを最初に検証し、ビジュアル方向を次に検証します。ユーザーが「ファストモード」、「あなたの判断」、「ただビルド」、またはロックされたブランドガイドを言ったときのみスキップします。

• ポインタークロームはオプトイン。 デフォルトではオフ。ブリーフがライブトーク、デモ、またはダーク/テックテーマを明示的に呼び出す場合、またはユーザーが「ライブプレゼンテーション」、「デモモード」、「カーソル効果を追加」を言うときにのみ有効にします。有効な場合、カスタムカーソル + マウスダウン スパークを使用します。ライブラリとワイヤリング → references/resources.md → Pointer & Click Feedback。ファストモードはブリーフがライブコンテキストを信号しない限り、ポインタークロームを有効にしません。

• マスタールールセットは references/slide-rules.md。 このファイルとフェーズドキュメントがデフォルトについて意見が一致しない場合、より具体的なルールが勝ちます; 解決を記録します。

エビデンス

• Octocode / ローカルツール リポジトリ構造、コードスニペット、API 動作、ローカルドキュメント、ユーザーファイル用。
• ウェブリサーチ 公開事実、現在の統計、外部のベストプラクティス、ライブラリドキュメント、ビジュアルインスピレーション用。
• ユーザーに質問 クレームが所有権、ビジネスセンシティブ、または利用可能なツールで検証不可能な場合。
• 検証事実から仮定を request.md で分離 (「assumed」をマーク)。検証されるまで仮定を見えるようにラベル付けしたままにします。

---

コンテンツ効率

成果物は作業が完了したことを証明するためではなく、次のフェーズを支援するために存在します。

• request.md、outline.md、DESIGN.md を可能な限り短く保ちながらも実行可能なまま。
• 成果物全体で長いソーステキストを重複させないでください。デック関連の事実、引用、コード、数字、リンクのみを保持します。
• 決定と追跡可能性にはテーブルを優先; 短縮するときのみ箇条書きを優先。
• 必要な場合のみ 1 つのバンドルされた質問です。ユーザーが「あなたの判断」、「ただビルド」、または十分なコンテキストを提供する場合、仮定を書いて続けます。
• 正しい深さで目標を達成する最小のデッキに最適化します。ハンサムなスライド数のためのパディングを避けます。
• アウトラインの行とインラインスライドノートは、スライドを構築するために必要なもののみを含む: 最終テキスト、スピーカーノート、推論、データ/アセット、ウィジェット/グラフ/画像、UX/UI ノート — リサーチダンプではなく。

---

質問する前に考える

ユーザーへの質問前にこの推論パスを内部で実行します — フェーズ 1 の明確化、フェーズ 3 のアウトラインゲート、フェーズ 4 のデザインゲート、または任意の段階ブロック。注意から質問しないでください。

ステップ 1 — 何を知っていますか？ ユーザーのリクエストとソース資料から抽出または自信を持って推論されたすべてのフィールドをリストします。明示的に仮定を書きます; それでもまだ進捗です。

ステップ 2 — 本当に何が未知ですか？ フィールドは両方が真実の場合のみ未知として適格です：

• (a) コンテキストから合理的に推論できず、かつ
• (b) 間違って推測することは聴衆、ストーリーアーク、ビジュアル方向、またはアウトプット形式を実質的に変えるでしょう

フィールドがステップ 1 または 2 に失敗する場合、それを推論し、assumed として記録します — 質問しないでください。

ステップ 3 — 未知を尋ねる価値はありますか？ ステップ 2 の後に未知数が残っている場合のみ質問します。それから：すべての未知数を1 つのメッセージにバンドルし、最も可能性の高い回答をデフォルトオプションとして事前入力し、最小労力の返信を明白にします (「続けるには 'good' に返信」またはオプション文字)。

ステップ 4 — 質問の前に推論を表示 すべてのゲートメッセージはこの形式に従う：

[構築/発見したもの]
[この選択をした理由 — 聴衆 + 目標に結びついた 1-2 文]
[選択肢または未知数、オプションとしてフォーマット]
[最小労力の返信パス]

質問の前に推論を表示すると、ユーザーは 1 語で選択を確認または修正でき、最初から再説明する必要がありません。

---

ユーザーへのオプション提示

複数のオプションを表示するすべてのゲートは1 つの正規フォーマットを使用します — 明確化質問を表示、アウトラインを表示、デザイン方向を提示、または事後レビューアクションを提供するかどうか。各回からこのフォーマットを定義せず、ゲートメッセージで定義します。

[コンテキスト: 構築されたものと理由]
オプション A — [説明]: [聴衆/目標シグナルに結びついた 1 行説明]
オプション B — [説明]: [1 行説明]
オプション C — [説明]: [1 行説明]

[最小労力の返信]: 「A」、「B」、または「C」に返信 — または調整内容を説明してください。

オプション提示ルール：

• 各オプションは文字 (A, B, C)、短いラベル、「この」聴衆と目標に結びついた 1 行の理由を持つ — 汎用審美ではなく
• オプションは意味があるように異なる必要があります — マイナーな色変動がある同じ選択ではなく
• 最小労力の返信は常に述べられている: 文字選択、「good」、または「continue」
• 2 つ以上のオプションを提示しないでください; もっと存在する場合、最も異なる 3 つを選択
• コンテキスト文はエージェントの推論を最初に説明します — オプションが次に来ます

このフォーマットをいつ使うか：

ゲート	オプションは何か
フェーズ 1 — 明確化	1 つの質問にバンドルされた未知フィールド
フェーズ 3 — アウトライン承認	ナレーティブアーク + スライド構造
フェーズ 4 — デザイン方向	3 つのビジュアル方向 (リンク済みプレビュー)
フェーズ 6 — 事後レビュー	次に何を変えるか

---

既存デッキの検証または編集

ユーザーが既にスライドを持っていて、レビュー、検証、監査、修正、または更新を求める場合 — フェーズ 1 から再開しないでください。ユーザーのニーズに基づいて正しいフェーズに入ります：

ユーザー意図	次で開始
「スライドをレビュー」 / 「品質をチェック」 / 「何が悪い」	フェーズ 6 — references/06-review.md を読み、完全なレビューを実行
「このスライドを修正」 / 「このコンテンツを更新」	フェーズ 5 — そのスライドの outline.md 行を再読、slides/slug.html を直接編集、フェーズ 6 ステップ 0 を再実行
「スライドを追加」 / 「スライドを削除」	フェーズ 3 → 5 — .content/outline.md を更新、ファイルを書き/削除、index.html の const slides を更新、フェーズ 6 を再実行
「テーマ / 色 / フォントを変更」	フェーズ 4 — DESIGN.md + css/theme.css を更新、フェーズ 6 ステップ 3 を再実行
「デッキを再構成」 / 「スライドを並べ替え」	フェーズ 3 — .content/outline.md を改訂、index.html の const slides 配列を並べ替え、Reasoning が変わるアウトラインの行を更新、フェーズ 6 を再実行

既存ファイルを編集する前に：

1. 最初に既存ファイルを読んでください — ブラインドに上書きしないでください。
2. コンテンツを変更する前に、そのスライドの .content/outline.md の関連行 (および任意の一致する Slide notes) をチェック、スライドの元の意図を確認します。
3. 任意の編集後、関連するフェーズ 6 チェック (完全なレビューでなく、コンテンツまたは構造が大きく変わった場合を除く) を再実行します。

.content/ フォルダが存在しない場合 (デッキはこのスキル外で作成): 純粋なファイルベースのレビューとしてフェーズ 6 を実行します。スライド HTML を信実の情報源として扱う。ユーザーがそれを求めない限り .content/ 成果物を作成しないでください。

---

ファストモード

ユーザーが**「あなたの判断」、「デザイン選択をスキップ」、「ただビルド」、「ファストモード」**、または同様のことを言う場合：

1. リクエストとソース資料から欠落したブリーフフィールドを推論; .content/request.md に仮定を記録
2. references/design-system.md のテーマ選択マトリックスから聴衆 + 目標に基づいてテーマを自動選択
3. スタイルプレビュー、デザイン承認、バッチごともユーザー一時停止をスキップ
4. コンテンツ方向が明白でない場合のみコンパクトアウトラインを表示; それ以外は続行
5. 選択されたテーマで DESIGN.md を書き、トップに > Auto-selected: … ノートを追加
6. 配信前に フェーズ 6 · ステップ 0 とブラウザ検証を実行 — Slop Test、コンテンツ、UX、アンチパターン、レンダリングされた出力

---

ライブラリ

スライドごとのみライブラリをロード — 各 iframe は別のドキュメントです。スライドの意図を提供する最も軽いツールを選択; 1 つのスライドで 2 つのチャートライブラリを読み込まないでください。

単一の情報源： references/resources.md — 完全な CDN URL、チャートライブラリ、アニメーションツール、コード レンダリングの決定テーブル。フェーズ 4 (デッキのライブラリを選択するとき) とフェーズ 5 (スライドにワイヤリングするとき) で読みます。

スライドタイプ → CSS クラス: section → slide--section · two-col → slide--two-col · stats → slide--stats · image → slide--image · その他すべてはマッチ。

---

Slop Test

2 つのテスト。すべての配信前に両方を実行します。

Visual Slop — シグナルごとに 1 ポイントスコア

#	シグナル
1	Inter または Roboto を唯一のヘッディングフォント
2	ヘッディングの background-clip: text グラデーション
3	すべての箇条書きまたはセクションの先頭に絵文字
4	すべてのスライドが同じセンター積み重ねレイアウトを使用
5	ダーク背景上のシアン + マゼンタ + パープル / ピンク パレット
6	カード上のアニメーション点滅 box-shadow
7	すべてのコードブロック上に 3 ドット ウィンドウクロム
8	スライドあたり 3 を超える要素上のアクセント色

スコア ≥ 2 → 配信前に フラグ付きシグナルを修正します。目標は 0/8; 最大 1/8 を許容します。

Content Slop — シグナルごとに 1 ポイントスコア

#	シグナル
1	スライドタイトルは名詞句であり、クレーム文ではない (「アーキテクチャ概要」、「重要なベネフィット」、「当社のソリューション」)
2	いかなる箆射也包含ガム言語: 「leverages」、「seamless」、「robust」、「powerful」、「next-generation」、「cutting-edge」、「innovative」、「world-class」
3	統計がスライドまたはスピーカーノートでソース引用なしで現れる
4	聴衆が既に知っていたスライド — 新しい情報は配信されない
5	終了スライドが「ありがとうございました」または「質問がありますか？」で終わり、CTA がない
6	クレームが曖昧であり、任意の業界の任意の製品に適用 — 具体的な数字、名前、または結果がない
7	ダイアグラムまたはフローが存在しますが、実際の正確な構造を表さない — それは概算または発明
8	画像は装飾的 (ムード、テクスチャ、ストックフォト) であり、情報的 (スクリーンショット、実ダイアグラム、直接エビデンス) ではない

スコア ≥ 1 → 配信前に修正します。修正内容に名前を付けます。目標は 0/8。

---

完了する意味

完全なハンドオフチェックリストは references/06-review.md ステップ 2 (技術的) とステップ 4 (コンテンツと流れ) にあります。ハイバーサマリー：

• デッキは npx serve .octocode/slides/{{slideName}} できれいに提供でき、コンソールエラーなしでレンダリング
• すべてのスライドはノースクロール、navbridge ロード、クレームタイトル、no-{{…}} チェックに合格
• index.html のマニフェストは { path, hidden, name } オブジェクトを使用、ユニークなスラッグ名
• Visual Slop ≤1/8 および Content Slop = 0/8
• 最終応答にはデックパスと提供コマンドが含まれる

参照ファイル

フェーズに入る前に、下記のそのフェーズの参照ファイル の Hard constraint ルールを読んでください。 ルールが既に満たされている場合は進行します; そうでない場合は、完全なファイルを読む前に解決します。

ファイル	目的	読むとき	Hard constraint
references/01-brief.md	リクエスト取得: ユーザー意図を理解、ソースを読む、request.md を書く	フェーズ 1	欠落するフィールドがデッキを実質的に変える場合のみ質問; 既に与えられた情報は決して質問しず、推論して assumed として記録。
references/02-research.md	リサーチ: ギャップを埋める、結果を request.md に追記	フェーズ 2	検証不可能なすべてのクレームを [NEEDS SOURCE] でマーク; データギャップを埋めるために発明またはパラフレーズしないでください。
references/03-outline.md	アウトライン: ナレーティブアーク + インラインノート付きスライドリスト	フェーズ 3	単一のスライド行を書く前に slide-rules.md §0 (聴衆と深さ) を読む — 深さレベルはすべての後続決定を支配します。
references/04-design.md	デザイン: 推論チェーン → 3 プレビュー → ユーザー選択 → DESIGN.md + CSS	フェーズ 4	いかなる審美的選択の前に デザイン推論チェーンを完了; 決してそれをショートカットしないでください — それはデッキが汎用テンプレートで終わる方法です。
references/05-implementation.md	実装: outline.md 行からスライドを構築	フェーズ 5	すべてのスライドは </body> の前に <script src="../js/navbridge.js"></script> を含める必要があります — これなしではユーザーがスライドをクリックした後、矢印キーナビゲーションが消えます。
references/06-review.md	レビュー: 技術的 + デザイン + コンテンツチェック	フェーズ 6	両方の Slop Test は配信前に合格する必要があります (Visual ≤1/8、Content 0/8); ユーザーに何も表示する前に失敗を修正します。
references/design-system.md	CSS コントラクト、デザインプロセス、アンチスロップガイド、リソース	フェーズ 4	スライド HTML で生の hex / rem / pixel 値はありません — CSS 変数 (var(--accent)、var(--t-title) など) をのみ使用します。
references/html-templates.md	すべてのスライドタイプ HTML テンプレート + <index.html> パターン + モーションパターン (scripts/base.css は CSS の情報源)	フェーズ 5	4 つの正規領域を順番に使用のみ: .slide-logo → .slide-header → .slide-content → .slide-footer; 必要ない領域を省略します。
references/resources.md	完全な URL とサンプル付きの CDN ライブラリ	フェーズ 4 + 5	スライドごとのみライブラリを読み込んでください — 各 iframe は別のドキュメント; スライド全体で グローバル ライブラリを共有しないでください。
references/slide-rules.md	マスタールールセット: コンテンツ、ビジュアル、レイアウト、ナレーティブ、UX、配信、アンチパターン、命名式	フェーズ 3 + 4 + 5	このファイルとフェーズドキュメント が意見が異なる場合、より具体的なルールが勝ちます; 解決を DESIGN.md またはアウトラインノートに記録します。
references/image-generation.md	オプション: Nano Banana 2 (Gemini 3.1 Flash Image) インテグレーション — 3 パス: A (Python SDK + GEMINI_API_KEY)、B (belt CLI)、C (Gemini CLI + mcp-nanobanana-go MCP、GCP ADC が必須); プロンプト、env パラメータのベストプラクティス、パス、オプトインルール	フェーズ 5 ユーザーが画像生成をオプトインするときのみ	画像を知らずに生成しないでください — ユーザーが明示的に「画像を生成」と言うときのみ。
references/animation.md	オプション: animation.js ステップエンジン — [data-step] マークアップ、CSS フック、読み込み順、ドット インジケータ、完全な例	フェーズ 5 スライドがアニメーション化されたステップごとの reveal が必要なときのみ	スライド内で steps を使用するすべてのスライドで animation.js を navbridge.js の前に読み込む — 間違った順序はインターセプトを静かに破壊します。

スクリプトファイル

scripts/ フォルダはテンプレートをそのままコピー保有します。生成されたすべてのデッキはそれらをそのままコピー：

ファイル	宛先	目的
scripts/base.html	index.html	ナビゲーションコントローラー (マルチ iframe ステージ、名前ハッシュ、概要、プレゼンター、HUD、B/W ブラックアウト、ホイールナビ)
scripts/slide.html	slides/*.html	スライド当たりテンプレート (4 領域スケルトン + LLM プレースホルダー)
scripts/base.css	css/base.css	レイアウト基元、タイプスケール、スライドタイプルール、コンポーネント、アニメーション、プリント
scripts/navbridge.js	js/navbridge.js	iframe キーイベントを親に転送 — すべてのスライドで必須
scripts/presenter.js	js/presenter.js	P キー プレゼンターポップアップ: 現在 + 次スライドプレビュー、スピーカーノート、タイマー、ジャンプ制御
scripts/animation.js	js/animation.js	オプション スライドごとのステップエンジン — 1 回に 1 つ [data-step] 要素を reveal on →; ← で逆に非表示; navbridge.js の前に読み込み必須

ルール: そのままコピー、決してパラフレーズしないでください。テーマオーバーライドは css/theme.css に存在; ワンオフレイアウトヘルパーはスライドのローカル <style> に存在。コピー後コピーされたスクリプトを編集しないでください。スライドごとライブラリ初期化 (hljs.highlightAll()、marked.parse()、mermaid.initialize()、Motion コール) は 1–3 行で、それらを必要とするスライドのインラインに滞留 — それぞれのスライドはそれらを使用しません。