Humanize PPT

このスキルは、ユーザーが生の素材、メモ、音声文字起こし、文書、リンクなどを、下流のスキルにレンダリングを委託する前に、プレゼンテーション可能なアウトラインとページごとのメディア決定に変換したい場合に使用します。古いPPT/PPTXファイルは直接読み取りません。最初にテキストを抽出し（scripts/pptx_qa.py のdump/inspect出力を参照）、そのテキストを --source として入力してください。Humanize PPTがすでにレンダリングしたデッキに対しては、代わりに --qa-from <rendered.pptx> を使用します。これはプレゼンテーションチェックアップであり、ブリーフモードではありません。

ポジショニング

Humanize PPTは プレゼンテーションシステムであり、トークのために生まれました。アウトラインディレクター（AST：Audience-State-Transfer。ページをめくるごとに聴衆を前進させる）、ページごとのビジュアルエンハンスメントディレクター（実際の画像/SVG図/Remotion動画）、プロダクションブリーフオーケストレーター、プレゼンテーションチェックアップランナー（演講体检、旧QAループ。CLIフラグは引き続き --qa-from）、および プレゼンターモードのハンドオフ を担当します。動機：HTML-PPTテンプレートスキルは 概念の表示 には優れていますが、単純なアイデアを12枚のきれいなページに膨らませてしまいます。一方、実際の90分のトークは約30ページです。つまり、きれいなシェルがコンテンツの密度を超えてしまうのです。Humanizeはそのギャップを埋めます。美しさは維持し（下流のテンプレートスキルがネイティブにレンダリング）、発表可能 にします。つまり、立ち上がって実際に話せるラインです。下流のテンプレートスキルは「美しくレンダリングする」ことを担当し、Humanizeは「それはトークであり、誰かがチェックしたもの」を担当します。

プレゼンテーションチェックアップを一文で表すと、美しさを評価するのではなく、アウトラインを評価します。レンダリングされた各ページをアウトラインページと比較し、見ることしかできず話すことができないページを抽出し、すべてのページがプレゼンターが立ち上がって発表できるものになるまで継続します。失敗ページとは、平たく言えば、数語しか持たず主張を完結させていないページ、または約束した聴衆の状態遷移を達成できていないページ（聴衆がそのページに入った時と同じ状態で出ていくページ）です。そのようなページは存在すべきではありません。チェックアップはそのページを抽出し、修正手順を生成します。

Humanizeは、プレーンマークダウンとJSONを消費できる下流のレンダラーと広く互換性があります。検証済みのルートは次のとおりです。中国語HTML → guizang-ppt-skill、英語HTML → frontend-slides / beautiful-html-templates、ネイティブ編集可能PowerPoint → ppt-master。その他の下流レンダラーもホットプラグ可能です。サポートレベルは registry/renderer_registry.json にあり、実際の出力があった場合にのみ変更されます。

このスキルは下流のPPT/HTMLスライドスキルの前、およびレンダリング後のプレゼンテーションチェックアップの周辺で実行されます。ASTコントラクト、ページごとのメディア決定（このページに写真、システム図、10秒のプロセスクリップ、何も必要なし？）、次のエージェントが消費するプロダクションブリーフ、およびレンダリングされたHTML/PPTXに対するチェックアップパスを担当します。レンダリングされたデッキ自体は所有しません。

レンダリング前に2つの人間によるレビューゲートがあります。アウトラインプレビュー とレンダラーのスタイルゲートです。HTMLルートはHumanizeの≥4枚の実際のカバー --style-gallery を使用します。PPT Masterはすでに必須の3段階確認UIとネイティブのビジュアルプレビューを持っているため、--renderer ppt-master --style-gallery はそのゲートに委譲し、style_gallery_plan.json + commands/style-gallery/ppt-master-confirm-ui.md を作成します（カタログを複製しません）。

ユーザーはHumanize PPTをブリーフのために1回呼び出し、そのブリーフを下流のスキルに渡してネイティブレンダリングを実行し、その後 --qa-from <rendered.html|native.pptx> を指定してHumanizeを再度呼び出し、3回のプレゼンテーションチェックアップを実行します。各反復で qa_report.md、fix_prompt.md、および qa_iteration.json が書き込まれます。3ラウンド後に残った失敗がある場合、ステータスは needs-human に変わります。

Humanize PPTは下流のスキルのテンプレートをコピーしたり、カスタムセクションを注入したり、レンダリングされたHTMLやPPTXを後処理したりすることは決してありません。修正は下流のオーサーソースに返されます。references/guizang-production-brief-orchestrator.md と adapters/ppt-master-bridge-notes.md を参照してください。

公的なポジショニングとしては、Humanize PPTをネイティブな下流レンダラーとペアになるブリーフオーケストレーターとして説明してください。それをレンダラー自体として位置づけたり、ユーザーにとって最適なビジュアルスタイルを選択する「ルーター」として提示したりしないでください。その決定はブリーフ、下流スキル自身のテンプレート、そして人間のレビューに委ねられます。ユーザーが単に美しいテンプレートページを欲しいだけなら、それはレンダリングスキルの仕事であり、Humanizeの仕事ではありません。選択肢を示してください。禁止ではありません。

AST理論

ASTは Audience-State-Transfer（聴衆状態遷移） の略です。

聴衆（Audience）：誰が聞いているのか、何を知っているのか、何に抵抗しているのか、なぜ聞き続けるのか。
状態（State）：プレゼンテーション前後の聴衆の状態、および遷移を妨げる中核的な緊張。
遷移（Transfer）：スライドごとの経路で、聴衆を初期状態から望ましい状態へと導く。

核となる一文：

PPTは情報を詰め込む箱ではありません。PPTは聴衆の状態を遷移させるためのアーティファクトです。

必須の出力契約

Humanize PPTの実行ごとに、以下を生成します。

deck_brief.md — 聴衆、目標、緊張、成功基準。
ast_outline.md — ASTマップとナラティブアーク。
slide_plan.json — スライドごとの計画、ページごとの media: {image, diagram, video} 決定と layout_hint。
speaker_intent.md — 各スライドでスピーカーが何をすべきか。下流スキルはこれをネイティブのスピーカーノートとプレゼンターシェルのソースとして消費します。
asset_manifest.md — Humanizeのページごとの素材決定。どのページにどの種類のアセット（画像/図/動画）が必要か、その目的は何か。
video_slots.json — オプションのRemotion/HyperFrames/ネイティブ動画挿入計画。
style_brief.md — 下流プロダクションのビジュアル原則。
renderer_registry.json — この実行のレンダラー機能スナップショット。
router_plan.json — 選択されたプライマリレンダラーと段階的なルート計画。
commands/*.md — 各下流専門エージェントへの制限付き指示。
run_manifest.json — 最終ファイルインベントリ、ルートステータス、QAステータス。
<renderer>-production-prompt.md — 下流エントリポイント。HTMLルートに加えて、ppt-master は ppt-master-production-prompt.md + 自己完結型の ppt-master-source.md と使い捨ての outputs/ppt-master-handoff/ コピーを出力します。
outputs/qa/qa_report.md — 初回パスQAゲート（ブリーフモード）または反復ごとのQA結果（QAモード）。

QAモード（レンダリング後）は反復ごとにさらに以下を生成します。

outputs/qa/fix_prompt.md — 下流スキルが実行可能な修正手順。
outputs/qa/qa_iteration.json — ラウンド番号、ステータス（iterate / pass / needs-human）、未解決の所見、履歴。

スタイルギャラリーモード（--style-gallery、アウトラインプレビュー前ゲート）は代わりに以下を生成し停止します。

HTMLルート：style_gallery.html および ≥4 のカバーエントリ。PPT Master：偽のギャラリーHTMLはなし。スタイル選択はネイティブのConfirm UIに残ります。
style_gallery_plan.json — HTMLのカバー候補、またはPPT Masterの場合は mode: downstream-confirm-ui。
commands/style-gallery/<id>.md — HTMLのカバーコマンド、またはネイティブゲート用の ppt-master-confirm-ui.md。

推奨OPCワークフロー（v0.6.4）

O — アウトライン + ページごとのメディア指示（Outline + Per-Page Media Direction）
  Humanize PPT: 生の素材 → ASTアウトライン + ページごとのメディア決定
  (deck_brief.md, ast_outline.md, slide_plan.json, speaker_intent.md,
   asset_manifest.md, video_slots.json, style_brief.md)

P — ネイティブレンダラーの呼び出し（100%下流）（Native Renderer Invocation）
  zh  → guizang-ppt-skill        (Style A または B、ネイティブ。推奨)
  en  → frontend-slides / beautiful-html-templates (ネイティブ。推奨)
  pptx → ppt-master (ネイティブDrawingML。明示的に --renderer ppt-master)
  その他のHTML-PPTスキル → ホットプラグ可能、同じブリーフ契約
  Humanizeはプロダクションプロンプトを出力して停止します。下流の
  スキルがデッキをレンダリングします。Humanizeはテンプレートをコピーせず、
  SLIDES_HERE / [必填] の置換を注入せず、レンダリングされたHTMLに
  postMessageブリッジを追加しません。

Q — レンダリングされたアーティファクトのプレゼンテーションチェックアップ（演講体检）（Presentation Checkup）
  Humanize --qa-from <rendered.html|native.pptx> はPの出力を読み込み、
  ページをアウトラインと比較し、障害モードをスキャンし
  (references/qa-failure-modes.md)、qa_report.md と
  fix_prompt.md を書き込み、反復を qa_iteration.json で追跡します。
  上限: 3ラウンド。上限到達後も所見が残っている場合、ステータスは
  needs-human に変わります。

C — 完了 / 制御（Complete / Control）
  下流スキルのネイティブスピーカーノート + プレゼンターシェル + デプロイ
  (Humanizeはv0.6.4ではこれらを所有しません。ブリーフは次の
  エージェントに、下流スキル独自の形式でそれらを生成するよう指示します。)

ルール

v0.6.4 不変条件（これらは厳格なルールです。これらを破ると、v0.6.4の境界を超えたことになります）

Humanizeはブリーフのみです。 レンダラー制作契約を書き、停止します。下流のテンプレートや最終的なHTML/PPTXを開いたり、コピーしたり、後処理したりすることはありません。
下流レンダラーは100%ネイティブです。 次のエージェントは下流スキル自身の SKILL.md に従います。ブリーフは、次のエージェントにどのスキルをロードするか、どのスタイル（A/B）を使用するか、どのレイアウトを選択するか、どのQAゲートを通過する必要があるかを指示しますが、テンプレート内部の情報は含みません。
プレゼンテーションチェックアップは最大3回です。 ラウンド4で失敗が残っている場合は needs-human です。ループは永久に回らず、決定を人間に戻します。
スピーカーノートとプレゼンターシェル — Humanizeはベースライン presenter-shell.html を生成します。下流が完全なステージを所有します。 Humanizeはセマンティックソース（speaker_intent.md）を所有し、さらに slide_plan.json + speaker_intent.md から直接 outputs/presenter/presenter-shell.html を書き込みます（下流デッキが存在しなくても単独で使用可能）。下流スキルはネイティブのスピーカーノートとより完全なプレゼンターコンソールを生成します。HumanizeはレンダリングされたHTMLに postMessage ブリッジや ?slide= URLパラメータを注入しません。
プロダクションプロンプトは下流エントリポイントです。 レンダラーが読み取らなければならないすべてのサポートアーティファクトを指定します。PPT Masterはさらに ppt-master-source.md を読み取ります。これはPPT Masterのビジュアル契約を複製することなく、Humanizeのページストーリーとノートの意図を固定します。

作業ルール

Humanize PPTが最初にAST契約を生成できる場合、スライドレンダラーに生の素材を直接消費させないでください。
下流スキルを完全なステージビューの所有者として維持します。Humanizeの presenter-shell.html は機能的なベースラインであり、ネイティブコンソールの代替ではありません。
AIライティングのクリーンアップ原則はヒューマナイザーツールから吸収しますが、Humanize PPTをテキストのポリッシュに矮小化しないでください。
広く未検証の約束よりも、小さく検証されたワークフローを優先します。
公開スキルリリースでは、リポジトリを作成/プッシュし、GitHubからローカルにインストールし、安全な完全サンプルを1つ実行し、検証済みの既知の良好なチェックポイント（examples/03-codex-guizang-native-ink-classic/）でブリーフとプレゼンテーションチェックアップを確認してから、READMEの詳細を仕上げます。
Agent Teams開発では、実際の下流スキルを配線する前に、router_plan.json、run_manifest.json、制限付きの commands/*.md、およびレンダラーごとのプロダクションプロンプトを出力します。
WorkBuddy/CodeBuddyチームアップロードパッケージでは、デモやレンダリングされたHTML出力をチームzipとしてパッケージ化しないでください。アップロードzipは、trading-team のようなチームプラグイン構造を反映する必要があります。ルートレベルの .codebuddy-plugin/plugin.json、agents/、skills/、rules/、および setting.json（オプションで avatars/、.workbuddy-plugin/、README.md、settings.json）。rules/ ディレクトリには、フロントマター（description、alwaysApply、enabled、updatedAt、provider）と、利用可能なエージェント、スキル、SOP、使用要件を説明する <system_reminder> ブロックを含むシナリオルールファイル（例：rules/<plugin-name>_rules.md）を含める必要があります。unzip -l を使用して、ルートが index.html/assets/screenshots/source ではなく、ターゲットのアップローダーが明示的にラッパーディレクトリを必要としない限りフォルダでラップされていないことを確認します。
HyperFrames/Remotion動画を、PPTコンテンツを置き換える単一の埋め込みプレーヤーとして扱わないでください。Humanize PPTの成果物では、動画ツールは素材プロデューサーです：トランジション、説明クリップ、ビフォーアフター比較、トーク用素材の挿入、ソーシャルプレビュー、特定のスライドニーズを満たすフォールバックスチル。ページごとの media.video 決定（slide_plan.json スキーマを参照）は、下流スキルにどのページがRemotionクリップを必要とするか、その目的、および期間を伝えます。

運用リファレンス

references/guizang-production-brief-orchestrator.md — 標準的なブリーフ仕様。<renderer>-production-prompt.md が含むべきものと含んではならないもの。
references/qa-failure-modes.md（+ 英語ミラー references/qa-failure-modes.en.md）— プレゼンテーションチェックアップの障害モードカタログ。コード側の信頼できる情報源は scripts/humanize_ppt_v2.py の FAILURE_MODES。
references/style-gallery-spec.md — --style-gallery カバースタイルゲート。
references/renderer-guidance.md — レンダラーごとの推奨パスと既知の良好なチェックポイントルール。
references/renderer-verification.md — フロントマターの一文の背後にあるレンダラーごとの検証エビデンス。
adapters/ppt-master-bridge-notes.md — ネイティブPPTXルートの境界とOOXMLチェックアップ契約。
SPEC.md — エンジン技術仕様：CLIサーフェス、データフロー、出力契約、スタイルギャラリー、チェックアップ、メディアモデル、レンダラーレジストリ。
すべてのリファレンス、アダプター、バージョンノート、ヘルパースクリプトの完全な注釈付きインデックス：docs/index.md。

ローカルデモ

推奨される安定したエントリポイントは scripts/humanize_ppt.py です（バージョン管理されたスクリプトは互換性シムとして残ります）。完全なCLIの例（ブリーフモード、プレゼンテーションチェックアップ、ネイティブPPTX、アウトラインプレビュー、レガシーエントリポイント）は docs/local-demo.md にあります。

--out の警告： --out は専用の実行ディレクトリを指定してください。ブリーフモードは実行のたびにディレクトリをゼロから再構築しますが、ディレクトリが存在しないか、空か、以前のHumanize PPT実行（run_manifest.json / style_gallery_plan.json / outline-preview.md / preview-confirmed.json がルートにある場合）である場合にのみ自動的に削除します。それ以外の場合は拒否し、--force を要求します。

Humanize PPT（プレゼンテーション・ブリーフ・オーケストレーター）