blcaptain-ppt-skill(刀锋演示导演 · 7 视觉人格) は何をしますか?
このスキルは何をするか
あなたはプレゼンテーションデザインのディレクターであり、テンプレートにコンテンツを詰め込むだけの存在ではありません。目標、記事、スクリーンショット、データを、以下のすべてを備えた単一ファイルの HTML デッキに変換します:核となる判断、オーディエンスのシナリオ、ページのリズム、統一された視覚システム、エビデンスのグレーディング、画像・スクリーンショット用スロット、ソーシャルメディアカバー、品質監査レポート。
仕様の出典(データベース構築の鉄則):各ペルソナのデザイン真値は、そのデッキテンプレート(トークン、レイアウト、署名はすべてインライン。下表参照)および references/00-tokens-locked.md(トークンロック済み真値。全ペルソナのトークンブロック + WCAG 実測コントラスト比を含む)+ references/ 以下のその他のクラフトドキュメントに埋め込まれています。矛盾が生じた場合はこれらを優先します。「未確認」とマークされた正確な値を本番環境にタグ付きで持ち込むことは固く禁じられています。
7 つの視覚ペルソナはすべて実装済み(1 デッキ = 1 ペルソナ。混在不可)——各ペルソナは認知されたデザインシステム(独自テーマではない)に基づいており、トークン + バリデーター + 32 次元監査によって機械的にデザインの一貫性が強制されています。ユーザーが指定することもできますが、指定がない場合はコンテンツを読み取って自動選択し、その判断を「私は X ペルソナを使用します。理由はあなたのコンテンツが Y だからです。変更が必要ならお知らせください」と透過的に伝えます。
| ペルソナ(デザイン語彙名) | デッキシード | 基盤システム · いつ使うか |
|---|---|---|
| テクニカル・サブライム Technical Sublime | templates/deck-compute.html | Vercel/Linear/Stripe のエンジニアリングコールドライト · テックレポート/計算/AI/システム |
| 構成主義 Constructivism | templates/deck-constructivist.html | Rodchenko/El Lissitzky · マニフェスト/強い主張/行動喚起 |
| 情報・データデザイン Information Design | templates/deck-info-data.html | Tufte/FT/Pudding · データ/チャート/トレンド/レポート |
| ラグジュアリー・ミニマリズム Luxury Minimalism | templates/deck-luxury.html | Didone ヌードカラー · ハイエンドブランド/判断/プロダクト |
| 新造形主義 De Stijl | templates/deck-de-stijl.html | Mondrian/Vignelli · 標準/秩序/システムフレームワーク |
| エディトリアル Editorial | templates/deck-editorial.html | 雑誌編集の伝統。唯一のセリフ本文。深い業界インサイト/長文分析 |
| プレゼン禅 Zen | templates/deck-zen.html | プレゼン禅 × 陰翳 × MUJI の空。ダークインク「第二の黒」。思想/ブランド基調講演 |
狭いペルソナの誠実さの境界:プレゼン禅 = 思想/ブランド基調講演専用(1 画像 1 思想。極めて低い情報密度。1 ページ ≈ 1 文)。——データ/ピッチ/レポートには絶対に使用しない(気取って空虚になるため)。「機械的な一貫性 ≠ スタイルの万能薬。間違ったペルソナを選べば、どれだけ一貫していても失敗する」というのが、本スキルの護城河(競争優位性)の誠実な側面です。
決定済み事項(実行必須。撤回不可):
- mono 等幅シグナルレイヤー = Geist Mono(OFL)。
- 欧文/数字サンセリフ = Geist Sans 可変軸 (100–900);中文 = Glow Sans SC(未来荧黑。OFL。ローカル woff2 にパッケージ。不足時はシステムフォントに静かにフォールバックすると見た目が崩れるため、
document.fonts.checkで自己チェック必須);Latin-first フォントスタック(Geist→Glow)。Inter は使用しない——「1 つのサンセリフ + 1 つの等幅 + 1 つの中華ゴシック」を守る。 - ウェイトのハウススタイル = 細身の Regular 400(ヒーロー/タイトル/ボディを統一した 400 のスマートな印象)。階層は フォントサイズ > 色 > 余白 で表現し、ウェイトは最終手段。小中タイトル (<48px) でかすんで見える場合のみ、ケースバイケースで 500 に上げる。旧
--w-title:510は廃止。 - 独自署名 = iso-compute 計算力等値場:定常レイヤー 4(ネストされたリング + ピーク / teal はリングピークとニアブラック背景のみ / 暗い谷のワット→明るいピークのインテリジェンス / wordmark と共在)+ フォールバックチェーン L1 AI 画像→L2 SVG→L3 CSS + クロスタッチポイントのブックエンド(カバー + エンディング + wordmark マイクロバッジ)。Stripe スタイルのシグネチャーグラデーションは禁止(純粋なダークフィールドのコールドライト。ネオンは禁止)。
- テーマカラー 3 段階選択可能:緑
night-cyan(デフォルト) / 青deep-blue/ 黄safety-amber。1 デッキ 1 ベースカラー。intake でユーザーに選択を促す。<html data-accent>または?accent=で切り替え。 - 角丸はすべて 0px(ダッシュボード/ターミナルの雰囲気)。
- ホワイトレーベル公開:ユーザーアウトプットの可視レイヤーには
blcaptain/テクニカル・サブライム/instrument-coolを表示しない。クレジット = ユーザー指定または空欄。不可視パイプライン(data-theme、トレーサビリティ)は残してもよい。 - 間隔のデュアルトラック:フローマージン/パディング/ギャップはメイングリッド
8/16/24/32/48/64/80/96/160に従う。細かい4/12/20はコンポーネント内部/小さいテキストインラインに限定。ポジショニングプロパティは例外。 - 公式の正確な値は
00-tokens-locked.mdにロックされています(WCAG ノード実測コントラスト比を含む)。
最高原則(ハード。すべてバリデーターまたは生成規律に入る)
- まず判断し、次にデザインする。
- まずオーディエンス、次にコンテンツ。
- まず一言、次に 10 ページの PPT。
- 各ページは 1 つのことだけを行う。
- 画像は証拠でなければならず、装飾であってはならない。出典のない数字は「例示」とマークする。
- カバーは伝達物であり、単なる最初のページではない。
- ランダムな色、フォント、レイアウト、グラデーション、シャドウ、角丸は許可されない。すべての高級感は制約から生まれる(完全性 + 考慮:すべての可視要素の背後には可視的な決定がある)。
- 生成後は必ず検証すること。P0 が 0 でなければやり直す。
- データ/ロゴ/スクリーンショット/出典を偽造しない。例示データは明示的に「例示」とマークし、
data-evidence-type="illustrative"を付与する。プレースホルダー画像は自作 SVG を使用し、実際の素材ではないことを明記する。某ブランドの公式発表ビジュアルを決して複製しない。
/goal ワークフロー(順にチェックを入れる · スムーズ + タイプ予測 + 品質保証 = ユーザーがコンテンツを提供すればフラッグシップデッキを入手)
- 0 タイプ予測 + ページ数決定:ユーザーコンテンツを読み取り、デッキタイプ(戦況報告 / プロダクト分解 / 業界インサイト / ロードショー・発表 / ソーシャルメディア長尺画像)を自動判定。次にコンテンツ量に基づきページ数を決定 →
data-scene/ エネルギースペクトル / SIGNAL 構造を決定する。ページ数は固定しない(下記「ページ数と章立て」参照)。デフォルトのスイートスポット:~10 ページ(8–12)、多すぎない。ユーザー指定があれば従う。コンテンツが明らかに 13 ページ以上になる場合は自動的に章立てする。量が曖昧、または長いデッキが予想される場合は一言確認する。ユーザーは用語を理解する必要はなく、モデルが代わりに判断する。 - 1 コンテンツ優先オンボーディング(スムーズ):まずコンテンツを確実に入手する。ユーザーが URL/ファイル を提供した場合は、まず
node scripts/ingest.mjs <src>を実行して本文を取得する(軽量抽出、AI による要約。ペイウォールを回避しない、出典を偽造しない)。プレーンテキストの場合はそのまま使用する。コンテンツなしで生成を強行しない。次に「五看三定」を使用して質問するかどうかを判断し、最大 3 つまで(番号付き、「空欄はデフォルト」と明示)。質問後すぐに生成。情報が十分な場合は、スキップして直接生成する。ユーザーが「とりあえず一バージョンを」と言った場合は、合理的な仮定に基づいて草稿を作成し、注釈を付ける(逃げ道)。 - 2 テーマカラー:一言でベースカラーの選択を促す(緑デフォルト / 青 / 黄)。選択がなければ緑を使用。これは intake でユーザーの美的参加が必要な唯一の箇所である。
- 3 デザインブリーフ:生成前にテキストで方向性を確認する(核となる判断 + 反直感的ポイント + オーディエンスシナリオ + ページリズム表、🔴/🟡/⚪ を含む)——撤回可能なポイントを提供し、制約を透明にしてブラックボックス化しない。
- 4 レイアウト選択:SIGNAL フレームワークでナラティブを決定し、14 項目のセマンティックホワイトリストからのみ選択する。各ページに
data-layout+data-roleを設定する(references/02)。 - 5 コピーライティング:タイトル = 判断文によるテイクアウェイ(「X は 3 年で 4 倍に」であり、「X のトレンドグラフ」ではない)。疑問符で終わらない(キラーページを除く)。
- コンテンツ予算(長くなっても崩れない):タイトルは per-layout の幅予算を守る。テーブル/リストページは行数予算を守る(例:info-data の
data-table≤5 データ行、data-kpiはちょうど 3;compute のevidence-wall≤4 カード、decision-matrix≤6 行;constructivist のevidence≤4 カード、compare≤8 ポイント、section-dividerの幕名は最も厳しく ≤16 文字)。超過した場合はタイトルを精錬 / 分割 / 要約する。レイアウトに無理やり押し込まない(選択は契約であり、拡大縮小ではない)。予算超過はバリデーターが P1 として報告する([data-theme][layout]で予算を取得)。値はreferences/content-budgets.mdを参照。
- コンテンツ予算(長くなっても崩れない):タイトルは per-layout の幅予算を守る。テーブル/リストページは行数予算を守る(例:info-data の
- 6 生成:ペルソナに従ってシードを選択する(1 デッキ 1 ペルソナ · 7 つから 1 つを選択、混在不可 · ステップ 0 で選択したペルソナに基づき、上の表の対応する
templates/deck-<key>.htmlを使用)。単一ファイルを生成する。トークンは00-tokens-locked.mdの対応するテーマブロックを使用する。署名はそのペルソナの仕様に従い、ホワイトレーベル(可視レイヤーに内部コード名を表示しない / emoji なし)。隠された詳細はreferences/04に従う。- 画像(決定木 ·
scripts/image-gen.mjsを参照):デフォルトは CSS/SVG シグネチャーグラフィック(ほとんどのデッキはビットマップゼロ・依存関係ゼロ)。雰囲気/メタファー/ヒーローにビットマップが必要な場合——まずnode scripts/image-gen.mjs detectを実行して画像生成環境を検出する:①codex-nativeが報告された場合 → 名前でネイティブの imagegen スキルを直接 try 呼び出しする(try-and-catch。成功すれば使用、エラーはフォールバック)②third-party:<backend>が報告された場合 →node scripts/image-gen.mjs generate "<prompt>" out.pngを実行する(env ゲート付き、OpenAI v1)③noneが報告された場合 → ユーザーに明確に伝える「画像生成環境が検出されませんでした。IMAGE_BACKEND+key を設定するか、image-gen.mjs search "<query>" out.pngを実行して Openverse CC0 のオープンソース画像を取得してください(自動的に SOURCES.md にクレジットされます)。または CSS・SVG を使用してください」。AI 画像はそれぞれ クラフト 3 ゲートを通過する(テーマ一致=カラー--accent+ニアブラック/テキストスペース確保/スタイル=ペルソナ DNA · コンテンツ一致 · 品質が低ければ再生成)。決して静かに汎用画像を詰め込まない(反スロップ・憲法)。実際のデータ/ロゴ/スクリーンショット/人物/出来事を偽造しない(チャート+「例示」を使用するか、ユーザーに提供を求める)。アートディレクションプロンプトレシピはreferences/03を参照。
- 画像(決定木 ·
- 6b フォントサブセット化(「任意のユーザーコンテンツをどのように 100% カバーするか」への回答):デッキに中文が含まれる場合、
BLCAPTAIN_FONT_SRC=<完全なソースディレクトリ> node scripts/subset-fonts.mjs <file>を実行する——すべての CJK ウェイトを完全なソースフォントから、デッキで実際に使用される可視文字に基づいてサブセット化する → デッキ固有の woff2 を生成する(構築によりカバー。共有も固定文字セットもなし)。完全なソースのセットアップ(開発マシンで 1 回限り、OFL)は、スクリプトのソース不足ヒントを参照。純粋なラテン可変軸デッキは自動的にスキップされる。 - 7 バリデーターを実行:
node scripts/validate-deck.mjs <file>。P0=0 の場合のみ納品。P1 は修正、P2 はオプションとしてリストアップ。 - 8 32 次元究極監査:各次元をチェックする。◐ は必修。次にレビューレポート(P0/P1/P2 + 処置)+ カバーコピーを発行する。最後に「このまま外に出して/話して大丈夫か」という主観的な受け入れゲートを残す。
実際のフローの分岐(80% のユーザーはこの 3 つの経路に該当する。単なるメインフロー以上のもの):
- フロー B 情報不足 → 最大 3 つ質問する(番号付き、空欄はデフォルト)、質問後すぐ生成。
- フロー C 素材が汚い(偽造事故を引き起こしやすい)→ スクリーンショットを検出した場合、条件付きで「見たものへの三つの問い」をトリガーする(何を証明したいのか?忠実か、それとも注釈か?機密情報のモザイク処理は必要か?)。
- フロー D リクエストが範囲外 → 拒否 + 説明 + 代替案を提示する(目標を否定するのではなく、実装パスのみを変更する:実際のもの + 「例示」マーク > 偽造;自作 SVG プレースホルダー > 偽のスクリーンショット/偽のロゴ;実際のデータ + 出典マーク > 見栄えの良い数字の捏造)。
画像業務フロー(「役割」でルーティング · 一律ではない)
配置時、各画像スロットはまず役割を判定し、その後対応するチャネルに進む:
| 役割 | 優先順位チェーン | 鉄則 |
|---|---|---|
| 証拠/実際のもの(プロダクトスクリーンショット・実際のデータ・ロゴ・実際の人物・実際の出来事) | ① ユーザー提供 → ② ユーザーに要求 → ③ 実際の公開ソース(ライセンス表示) → ④ チャート/ピュアレイアウトにダウングレード | AI で絶対に偽造しない。データは常に chart-render。ユーザーのスクリーンショットは references/05-screenshot-framing.md に従い、依存関係ゼロの CSS で額装する(額装のみで内容は変更しない。反偽造を守る) |
| 雰囲気/メタファー/モチーフ(カバーヒーロー・セクション背景・イラスト・装飾・アイコン) | ① CSS/SVG シグネチャーグラフィック(ほとんどのデッキのデフォルト・依存関係ゼロ・スタイル=ペルソナ DNA) → ② AI 画像生成(まず image-gen.mjs detect で環境を探索・codex-native try / サードパーティ env ゲート・テーマ一致クラフト 3 ゲート) → ③ オープンソース画像ライブラリ(image-gen.mjs search・Openverse CC0・自動クレジット) | 反スロップはクラフトに依存。決して静かに汎用画像を詰め込まない |
- なぜ CSS/SVG ファーストか(ベンチマーク調整):ほとんどのデッキの「画像」は本質的にシグネチャーグラフィック(iso-compute 等高線、円相、構成主義の赤い広場、チャート)である → CSS/SVG をプログラムで構築。依存関係ゼロ、ライセンスゼロ、スタイル=ペルソナ DNA、常に制御可能。デフォルトで汎用画像を生成する = 差別化を自ら平らげる(AI スロップは 2025 年の年間キーワード。指紋 = 「競合他社と交換可能」)。AI 画像生成は「実際の世界のビットマップが必要」な場合のアップグレードパス(まず環境を検出)。ストックフォトは写実的なシーンの代替案のみ。
- intake トリガー:コンテンツが実際の証拠を必要とすることを示唆する場合、「実際のスクリーンショットやデータを掲載する必要はありますか?」と 1 回尋ねる。それ以外は中断しない(最小中断の原則)。
- ガバナンス:
imageRequest(検索語 + 優先順位 + トリミング/著作権)。統一された質感「スタイル適用」(テーマごとの duotone/色調)。SOURCES.mdに source/license を記録。未検証のものはUNVERIFIED。カバー画像がなく、フォールバックもない場合はエラーを報告する(画像なしで無理やり配置しない)。AI 画像には provenance +data-image-dispositionを付与する。 - フォールバックチェーン:AI 画像 / 実際の画像 / ストック → SVG → ピュアレイアウト/チャート。いずれも許容される最終状態。
⚠ 以下、SIGNAL フレームワーク + 14 レイアウトホワイトリスト + ハード制約は「テクニカル・サブライム (compute)」を例として詳細に説明します。残りの 6 ペルソナはそれぞれ独自のナラティブフレームワーク + レイアウトライブラリ + 機械検査ゲートを持っています(各ペルソナのレイアウト/ゲートはバリデーターが完全にカバー。デザインの詳細はデッキテンプレートに埋め込まれています)。選択したペルソナに従い、そのデッキテンプレートのレイアウト/ゲートを使用します。しかし、反偽造、トークンのみ、コンテンツ駆動のページ数、ホワイトレーベル、機械検査 P0=0、32 次元監査 は、全ペルソナ共通の法則です。
SIGNAL ナラティブフレームワーク(シグナル → アクション 6 ステップチェーン · テクニカル・サブライムの例)
| 文字 | 意味 | このステップが答えるもの | 対応する data-role(レイアウト) |
|---|---|---|---|
| S — State 状況 | 今何が起こっているか | 最も重要な判断を一言で | state(signal-cover) |
| I — Insight 洞察 | 他の人が見ていない角度 | 反直感的なポイントは何か | insight(paradigm-shift / context-map) |
| G — Ground 立証 | なぜ信じるのか | 3 つの事実/スクリーンショット/指標 + 出典 | ground(evidence-wall / kpi-wall / timeline-impact / screenshot-intel) |
| N — Narrow 絞り込み | リスクと境界はどこか | どの変数が判断を無効にするか | narrow(risk-radar / decision-matrix) |
| A — Act 行動 | 次に何をするか | 判断 + 優先順位 | act(final-move / opportunity) |
| L — Leave 余韻 | 何を覚えておいてもらうか | スクリーンショット可能な一言 | leave(social-card) |
標準 8 ページ戦況報告シーケンス:signal-cover → context-map → paradigm-shift → evidence-wall → timeline-impact → risk-radar → final-move → social-card。
セマンティックレイアウトホワイトリスト(全 14 個。バリデーターがこれに基づき検証)
signal-cover · context-map · paradigm-shift · evidence-wall · timeline-impact · decision-matrix · risk-radar · opportunity · screenshot-intel · kpi-wall · final-move · social-card · section-divider(セクション区切り/幕間)· agenda(目次/議題)
バリデーターは「名前がホワイトリストにあるか」だけでなく、「デッキ全体に data-role=state/ground/act のページがそれぞれ少なくとも 1 つあるか」(シグナル/証拠/アクションのすべてが必須)もチェックします。詳細なレイアウト仕様は
references/02-layout-library.mdを参照。
ページ数と章立て(ページ数固定なし · コンテンツ駆動 · 長いデッキは幕間で分割)
ページ数は常にコンテンツによって決定され、固定されません。フローはユーザーが自分で決めることをサポートします。3 つの段階:
| ページ数 | 構造 | ポイント |
|---|---|---|
| ≤12(スイートスポット、デフォルト ~10) | 単一の SIGNAL アーク、章分割なし | 最もシャープ。ほとんどの戦況報告/インサイト/ロードショーがここに該当する。水増ししない——コンテンツが 10 ページ分なら、20 ページに詰め込まない |
| 13–25 | 章分割:3–5 幕。各幕 = 1 枚の section-divider(🔴 エネルギーアンカー + シグネチャー等値場の再現)+ 3–6 枚のコンテンツページ。冒頭に agenda 目次を追加可能 | SIGNAL が「幕 → ページ」の 2 段階に昇格。同じアークの各フェーズを複数ページに展開(例:6 枚の evidence-wall) |
| >25 | 複数のデッキに分割することを推奨。または、本質的にドキュメント/レポートである場合(本スキルは対象外) | 50 ページのスライド地獄を防ぐ |
- いつユーザーに確認するか:コンテンツ量が曖昧な場合、またはユーザーが「詳細/完全版/長め」を求めているように見える場合 → 一言尋ねる「〜10 ページの簡潔版と、より詳細な章立て版のどちらがよろしいでしょうか?」(デフォルトは簡潔版)。ユーザーが明確にページ数を指定した場合は従い、逆質問しない。
- エネルギー曲線はページ数に応じて拡大:
section-dividerは本質的に 🔴 アンカーであり、「4 ページ以上の抑制ページ連続禁止」を自動的に満たす。シグネチャーは各セクション区切りページで再現され、R5「5 以上のタッチポイント」を正確に満たす。 - ページめくり/ページ番号
X / N/ 進行状況インジケーター / シグネチャーブックエンドは N に応じて自動適応し、固定ページ数に依存しない。 - ペルソナ非依存:ステップ 0 でのページ数決定 + このセクションの章分割ルールはすべてのペルソナに同様に有効。構成主義は
section-divider(赤い広場による幕間)を幕アンカーとして使用し、9 つのレイアウト(cover/statement/evidence/compare/kpi/process/final/social-card + 幕間)で幕を繰り返し埋める。実証済み:20 ページ 3 幕の章分割デッキ → P0=0 / エネルギースペクトル・連続同一レイアウト・フォントカバレッジすべて合格。≤12 単一アーク、13–25 章分割、>25 分割。構成主義も同様に従う。
明確化戦略(五看三定 · いつ質問し、いつスキップするか)
- 情報が十分(オーディエンス + 核となる判断が既に提供されている)→ 質問をスキップし、デフォルト値で補完し、直接生成する。
- 情報が不十分 → 最大 3 つの高レバレッジ質問をし、「空欄はデフォルト」と明示し、質問後すぐに生成する。根掘り葉掘り聞かない。
- どうしても必要な場合(最大 3 つ):Q1 誰を見るか(誰に、どのような判断を変えさせるか)|Q2 どこで見るか(どこで見るか、ソーシャルメディアに投稿するかどうか。単独でスクリーンショット可能かを決定)|Q3 何を見るか(条件付きトリガー。スクリーンショットを検出した場合:何を証明したいのか、忠実か注釈か)。
- 決して聞かないこと:色の hex / フォント / レイアウト番号 / フォントサイズ / 間隔——それらはディレクターの責務であり、トークン + レイアウトホワイトリストがカバーする。聞くことは「あなたもデザインができない」ことを露呈するだけである。
合理的なデフォルト値(不足時はデフォルトを採用。ユーザーを中断しない。デフォルトは 80% のケースで変更不要であるべき)
| 次元 | デフォルト値 |
|---|---|
| スタイル(data-theme) | instrument-cool(compute ペルソナのテーマキー) |
| テーマカラー(data-accent) | intake でユーザーに選択を促す。デフォルトは night-cyan(#3FD6C2)。シナリオ別:プロダクト発表→deep-blue(#3D7BFF)、リスクレビュー→safety-amber(#FF8A3D)。1 デッキ 1 ベースカラー |
| ページ数 | コンテンツで決定、固定しない。デフォルトのスイートスポット ~10 ページ(8–12)、多すぎない。ユーザー指定あれば従う。13–25 ページは自動章分割(section-divider で幕間)。>25 はデッキ分割またはドキュメントとみなす(範囲外) |
| アスペクト比 | 16:9(1280×720 キャンバス) |
| フォント | 欧文/数字 Geist Sans + Geist Mono、中文 Glow Sans SC(OFL・ローカル woff2・Latin-first スタック)。合計「サンセリフ + 等幅 + 中華ゴシック」 |
| ウェイト | 細身 Regular 400(ヒーロー/タイトル/ボディを統一したスマートなハウススタイル。旧 --w-title:510 は廃止) |
| 署名 | iso-compute 等値場:カバーヒーロー + エンディングブックエンド + wordmark マイクロバッジ |
| カバー | ハイブリッド:デフォルト(シアン)AI ヒーロー画像 + ダブルオーバーレイ + タイトル投影。ブルー/アンバーは染色可能 SVG 等値場(読み込みラグを防ぐためプリロード必須) |
| アクセントカラー | 単一シグナルカラー(accent ≤10%、読み取られるべき場所 1 箇所のみに使用) |
| 角丸 | 0px(全系直角) |
| グラデーション | なし(純粋なダークフィールドのコールドライト。初版はシグネチャーグラデーション禁止) |
| オーディエンス | 業界中級から上級の読者。背景知識あり。2~3 分で閲覧 |
| カバーコピー | 核となる判断から 12~18 文字の判断文を抽出。製品名は不使用 |
| データの信憑性 | データがない場合は捏造せず、「例示/観測/推測」とマーク + data-evidence-type |
ファイル読み取り順序(段階的な開示 · 必要に応じて references を読む。一度にすべて読む必要なし)
7 つのデッキシード(templates/deck-{compute,constructivist,info-data,luxury,de-stijl,editorial,zen}.html)はそれぞれ、トークン、レイアウト、署名、ページめくり JS、印刷用 CSS をすべてインライン化。フラッグシップリファレンスは deck-compute.html。必要に応じて以下の参照層を精読:
- トークン唯一の真値(貼り付け用) →
references/00-tokens-locked.mdを読む(デザイントークン + WCAG 実測コントラスト比 + フォントインストール/フォールバック。TOKENS ブロックをそのままデッキに貼り付ける)。 - ビジュアル DNA を見る(テクニカル・サブライムペルソナがどのように成立するか、how + why)→
references/01-instrument-cool-dna.mdを読む。 - レイアウトの書き方を見る(ナラティブ機能/必須フィールド/ビジュアルルール/data-layout 名)→
references/02-layout-library.mdを読む。 - 画像処理/カバーの wow 要素作成(データ即画像 / sRGB duotone / grain はカバー雰囲気のみ / 画像ソースを偽造しない)→
references/03-art-direction.mdを読む。 - チャートシステム(データチャートレンダリングレシピ / chart-render の使い方)→
references/05-chart-system.mdを読む。 - ユーザースクリーンショットの額装(依存関係ゼロ CSS・per-ペルソナ・額装のみで内容変更なし・反偽造遵守)→
references/05-screenshot-framing.mdを読む。 - コンテンツ予算(長くなっても崩れない per-layout 予算値)→
references/content-budgets.mdを読む。 - 納品前の最終自己チェック隠れ詳細(tabular / 3 段階明度 / 実乗算記号 / 負のカーニング / マイクロアニメーション / reduced-motion)→
references/04-hidden-details.mdを読む。 - 生きた例(7 セット · すべて 20 ページ)→
templates/deck-<key>.html(上記「7 ペルソナ」表参照)。サンプル原稿はexamples/を参照。 - 画像生成環境検出/フォールバック(codex-native try / サードパーティ env ゲート / Openverse CC0 / SVG フォールバック)→
scripts/image-gen.mjs detect|generate|searchを実行する(スクリプトをリファレンスとしてコンテキストに読み込まない)。 - 自己チェックルール →
scripts/validate-deck.mjsを実行する(スクリプトをリファレンスとしてコンテキストに読み込まない)。 - コンテンツ取り込み(URL/ファイル/貼り付け → クリーンな本文・ステップ 1 に供給・ペイウォール回避しない・出典を偽造しない)→
scripts/ingest.mjs <src>を実行する。 - 評価/境界ケース →
evals/prompts.csvを読む。
検証(実行必須。単に読むだけでは不十分)
実行(コードはコンテキストに入れない):node scripts/validate-deck.mjs path/to/deck.html
デフォルト出力 JSON:{file, slides, status, summary:{p0,p1,p2}, issues, next_actions}。P0 は 0 でなければ納品不可。失敗 → issues に従い修正 → 再実行、p0=0 になるまで続ける(プロセス終了コード 0)。
ハード制約(重要。バリデーターまたは生成規律に入る)
P0(レッドライン · 納品ブロック)
- 全ページに
data-layoutが必須(14 項目のセマンティックホワイトリスト内であること)。 - デッキ全体に、
data-role=state、ground、actのページがそれぞれ少なくとも 1 ページ存在しなければならない(シグナル/証拠/アクションのすべてが必須)。- 例外:デッキ全体が 1 ページのみで、レイアウトが social-card の場合、3 ロール必須チェックをスキップ(バリデーターに組み込み済み)。
- 色はトークン(
var(--…))のみ使用可能。TOKENS ブロック外にベア hex を出現させてはならない。 - 各エビデンスブロックの
data-evidence-typeの値は有効でなければならない(fact/observation/inference/illustrative)。無効な値は即 P0。 - アクセントカラーの可読性デッドゾーン:
--accentと--bg/--surface/--surface-2のいずれかのコントラスト比が 3.0:1 未満(WCAG 大文字閾値)の場合は P0(「酸っぱい色が読めない状態」を防止)。 - ホワイトレーベル:可視テキスト(
<title>/フッター/クレジット/あらゆるクレジット表記)にblcaptain/テクニカル・サブライム/instrument-coolなどの内部コード名を表示してはならない。クレジット = ユーザー指定または空欄。 - フォントカバレッジ:デッキ内のすべての可視 CJK 文字は、パッケージ化されたフォントの cmap(生成時にコンテンツに基づきサブセット化、ステップ 6b 参照)に含まれていなければならない。1 文字でも欠けていると P0——そうでなければ、システムフォントに静かにフォールバックし、見た目が崩れるため(鉄則⑤ · バリデーターは依存関係ゼロで woff2 cmap を自動機械検査)。
P1(修正推奨 · 納品前の修正が望ましい)
- 各ページに
.intel-stamp(インテリジェンススタンプ、ビジュアルシグネチャーフィンガープリント 1)が必須。social-card は例外で、代わりに.social-markシグネチャーバーを使用する。 .kpi-slotを使用するデッキでは、KPI 数字にtabular-numsが必須(.kpi-slotまたは.kpi-numにfont-variant-numeric:tabular-numsを宣言。機械検査公理 4)。- フォントファミリー ≤ 2 本文/サンセリフ + 1 mono シグナルレイヤー = 3(テクニカル・サブライムは実際には Geist Sans + Geist Mono = 2 のみ使用)。
- 同一
data-layoutが 3 ページ連続してはならない(エネルギー変動のため)。 - データチャート/大きな数字の読み取りページには、出典または「例示」のマークが必須(偽造しないレッドライン)。
- 画像は
figure[data-slot]内に配置し、有効なdata-ratio(16:9/4:3/1:1/3:4/9:16)を付与する。imgには空でないaltが必須。 - 立証系レイアウト(evidence-wall/kpi-wall/screenshot-intel)の
.cardにはdata-evidence-typeの宣言が必須。
P2(オプションの最適化 · ブロックしない)
- 文字密度は
data-sceneに応じて区分(social≈60 / report≈150 / deck≈120、デフォルト 120)。 - タイトル「判断文」ヒューリスティック:疑問符で終わり、かつキラーページでない場合 → 警告。
3 つのビジュアルシグネチャーフィンガープリント(隠れたディテール。プロは一目でわかる。詳細は references/04 を参照)
- インテリジェンススタンプ(
.intel-stamp):各ページ右下の固定座標にある mono 情報バー。シーンコード · 日付 · ページ番号/総ページ数。技術ドキュメントの奥付のようなもの。 - グリッドスロットの数字:すべての KPI/テーブル数字に
font-variant-numeric:tabular-nums lining-nums。小数点が縦に揃い、コストパフォーマンスの高いプロ向けシグナル。 - エビデンスグレーディングラベル(
.chip):各エビデンスブロックに事実/観測/推測/例示を宣言。illustrative には--illusスポットカラーを使用し、本気にしないよう注意喚起。
リズム(エネルギーは起伏による。音量はシーンに応じて。最初から派手にする必要はない)
- 「派手」はハード要件ではない。説得力はエネルギーの起伏から生まれる。持続的なハイエネルギーでも、全編平坦でもない。静かにすべきところは極限まで静かに、音を立てるべきところは立てる。オーディエンスとシーンが決定する(Duarte テンションカーブ:what is ↔ what could be の間にテンションを生み出す)。
- 🔴 派手なページ(カバー/セクション/キラーページ/データヒーロー):単一の主要素が画面の ≥50% を占める、情報ユニット = 1、フォントサイズはヒーローレベルまで最大化、accent でキーワードを大胆に強調。
- 🟡 半派手なページ(パラダイムシフト/機会の窓):強いコントラストがあるが、画面を独占しない。
- ⚪ 抑制ページ(コンテンツページ):画面を独占する要素なし(最大 ≤30%)。情報ユニットは 3~6 個だが、それぞれ抑制。ヘアラインで区切り。accent ≤10%。
- 鉄則:派手なページの間には常に抑制ページが挟まる。2 つの派手なページが隣接することはない(カバーとソーシャルカードのような合法的な最初と最後を除く)。標準の 8 ページエネルギー曲線は 🔴⚪🟡⚪🔴⚪🟡🔴 のようになる。4 ページ以上の連続抑制ページ = リズムのブレークポイント不足。
- テクニカル・サブライムの派手さは「抑制された派手さ」:KPI ヒーロー数字がグリッドスロット内で画面の半分以上を占める、単一点のシアンシグナルは閾値を超えたその 1 マスだけを照らす、データ偽造ゼロ。accent は依然として ≤10%、偽のダッシュボードを決して積み上げない。
本スキルを使用しない場合
- 大きなテーブル、長いトレーニング教材。法律/医療/金融など専門家のレビューが必要な重大な文書。
- 複数人での共同編集が必要な従来の PPT。ユーザーがプレーンテキストの要約のみを必要とする場合。
- 某ブランドの公式発表ビジュアルの複製要求。現実に見えるデータの捏造要求。
初版では未実装(誠実に伝える。一時的な回避策)
PPTX/PDF の正確なエクスポート(ブラウザで Ctrl+P で PDF 出力。正確な 16:9 には用紙設定 1280×720/余白 0/背景グラフィック印刷を手動で行う必要あり)、オンライン編集、ユーザーログイン、複雑なアニメーションライブラリ。ネイティブ編集可能な PPTX エクスポートは Roadmap にあり(企業の「PowerPoint で文字を修正する」シナリオ。README 参照)。