academic-figure-workflow

学術図ワークフロー

根拠に基づいた学術図を作成し、安定したローカル成果物を生成します。ユーザーが選択したバックエンド、参照アセット、スタイルの方向性、レビューの希望、出力範囲を維持してください。

ユーザーが図のプロンプトの作成、診断、または修正だけを求めている場合は、このスキルに該当する出力モードを使用し、レンダリング前に停止してください。プロンプトのみの依頼では、レンダリングパスを捏造したり、追加の承認段階を設けたりする必要はありません。

科学的内容を、検収可能な図にまとめます。ここが唯一のデザインおよびプロンプト編集の入り口です。プロンプトの修辞を、2度目の科学的デザインとして扱ってはいけません。

リクエストに応じた出力の選択

ユーザーの意図	行動と停止地点
作図プロンプトを作成する／プロンプトだけを書く	construct：デザインブリーフと完全なプロンプトを作成し、画像は生成しません
既存のプロンプトを確認または診断する	diagnose：問題、影響、最小限の修正を特定し、ファイルの変更や画像の生成は行いません
フィードバックに基づいてプロンプトを修正する	revise：変更点、維持する項目、完全な新しいプロンプトを提示し、自動的に画像を生成することはありません
図を作成する／画像を修正する	construct または revise の後、このスキルでレンダリングと目視確認を続けます
配色またはスタイルについてのみ相談する	Palette Decision：完全なトポロジーは要求せず、画像も生成しません
AI 画像内のテキストを編集可能な PPT にする	references/editable-pptx.md に従ってチェックリストを作成し、PPTX を組み立てます。元の PNG は変更せず、別のスキルも開始しません

案の相談だけの場合は、作図を開始しません。直接作図する場合は、プロンプトの確認を強制せず、ユーザーのレビューの希望に従って実行します。直接作図しても、スタイルの選択を代行することにはなりません。

必要なものだけを読み込む

現在の段階で必要なものだけを読み込みます。

• 作成、診断、修正の判断 → references/prompt-design-logic.md
• renderer prompt の編集 → references/json-to-prompt.md
• そのまま記入できる作成／修正用テンプレート → references/prompt-templates.md
• 密度、レイアウト、テキスト、スタイルの詳細 → references/image-prompt-guide.md
• 事例と移行テスト → references/prompt-design-cases.md
• 実際のレンダリングの構造契約 → json-schema.md と figure-spec.schema.json
• 視覚的なアンカー → references/architecture-icons.md。根拠に合致する要素のみを使用します
• 初回の画像生成前に確認するスタイルメニュー → references/style-catalog.md と references/previews/
• 色と任意のスタイルライブラリ → references/palettes.md、references/styles/
• Codex native image execution → references/codex-image-workflow.md
• 画像の検収 → references/render-audit.md（画像を受け入れる前に必須）
• 編集可能な PPT のテキスト → references/editable-pptx.md。ラスター画像を納品するときは、対応可能であることだけを伝えます。ユーザーがその画像を受け入れ、編集可能なテキストを求めた後に限り、読み込んで組み立てます

根拠を超える内容は推論または要確認として明記します。モジュール、損失、次元、結果を捏造せず、プレースホルダーを使用します。利用可能な情報源がない場合は停止し、最低限必要な追加資料を列挙します。

確認した内容に基づいて入力を振り分ける

URL が自動的にリポジトリとして扱われるわけではありません。まず内容を確認してください。

入力	振り分け先	実行動作
ユーザーから直接提示されたアーキテクチャ（そのまま使用）	このスキルのデザインフロー	アナライザーをスキップします。ユーザーがノードとフローを明示しているため、FigureSpec v1 を編集し、そのままレンダリングします。
下書きメモ／アウトライン／部分的な原稿	../academic-figure-analyzer/SKILL.md	下書きから図へのファストトラック。粗いメモ、アウトライン、または完全な結果を含まないセクションでは、Figure 1 のフレームワークに重点を置きます。
完成した原稿（Markdown／LaTeX／PDF／URL）	../academic-figure-analyzer/SKILL.md	完全な計画。実験や結果を含む論文では、複数の図の戦略、主張の検証、制約の確認を行います。
リポジトリのパスまたは URL	../academic-figure-analyzer/SKILL.md	意味的なアーキテクチャグラフを抽出し、エンジニアリング上の配線（データローダー、トレーナー）は除外します。
論文とリポジトリ	../academic-figure-analyzer/SKILL.md	論文／ユーザーがナラティブとトポロジーを定義し、リポジトリはパラメーターと次元の検証に使用します。
外部のスタイル参照	../academic-figure-analyzer/SKILL.md	外部参照から応用可能なスタイルを抽出します。
編集対象の既存レンダリング画像	このスキルの revise モード	科学的内容、トポロジー、表示テキストを維持したうえで、要求された差分のみを適用します。

論文の URL には、利用可能な Web／ブラウザー／ドキュメントリーダーを使って、論文本文、キャプション、リンク先の図を取得します。PDF には、論文の内容を読み取れる PDF 対応リーダーを使用します。academic-figure-analyzer がインストールされていない場合は、同等の最低限の分析を実施し、機能が制限された手順であることを明記します。

バージョン管理された内部成果物を保持する

以下を JSON 互換のオブジェクトとして保存します。要求がない限り、ユーザーに読ませないでください。

FigurePlan v1

schema: academic-figure/FigurePlan@1
source_revision, venue
sources[]: {kind, uri_or_absolute_path, revision_or_page, evidence}
figures[]: {
  figure_id, figure_type, priority, communication_goal, claim_scope[], hero_element,
  required_nodes[], required_connections[], authority_boundaries[], secondary_context[],
  forbidden_claims[], forbidden_connections[], aspect_ratio, final_width_mm,
  style_profile_hint, reference_assets[],
  open_questions[], confidence, review_status: pending|confirmed|waived
}

コンポーネントと接続は、意味に基づき、根拠で裏付けられている必要があります。コードディレクトリの数を、図の階層や配色の判断として扱ってはいけません。

FigureSpec v1

schema: academic-figure/FigureSpec@1
figure_id, plan_revision, sources[], prompt (internal), aspect_ratio, final_width_mm
topology: {components[], connections[], groups[], authority_boundaries[]}
visible_text[], caption_notes[], layout
style_profile: classic-technical|pastel-airy-ui|illustrated-modular|reference-led
style_preset, style_source, style_grammar, semantic_color_roles
style_selection: pending|confirmed|waived (render-ready rejects pending or missing)
reference_images[]: checked absolute local paths or recent-conversation descriptors
conversation-reference transient status stays in the execution packet
must_not_claim[], forbidden_connections[], negative_constraints[]
prompt_review: requested|confirmed|waived
prompt_reviewed_sha256: required only when prompt_review is confirmed
workspace_root: absolute declaration that must match the runtime-trusted root
output_path: absolute path inside that root

内部の prompt は renderer への入力であり、ユーザー向けに必ず提示する成果物ではありません。 prompt_review が waived の場合は、作業用成果物とともにのみ保存し、 チャットの回答に貼り付けてはいけません。

RenderAudit v2

schema: academic-figure/RenderAudit@2
figure_id, render_revision, image_path, image_sha256, spec_sha256
spec_validation: {status}
image_inspection: {status, evidence}
nodes[]: {id, status, evidence}
edges[]: {id, from, to, kind, direction, line, label, status, evidence}
checks: {semantic_topology, visible_text, background, layout,
         style_fidelity, accessibility} (each: {status, evidence})
pass, defects[], targeted_edit, semantic_edits_used, semantic_edits_remaining

ステータスは pass|fail|unverified です。正確なリビジョンの紐付け、グラフ全体の網羅、および集約パスの要件については、共有監査プロトコルを参照してください。過去の v1 監査は履歴として保持し、新しいレンダリングには v2 の検査記録が必要です。

プランを作成する

科学的な曖昧さを解消する、最短の FigurePlan を作成します。最短とは、推測に基づくモジュールを含めないことです。実行された経路上にあるステーションは、重要度が二次的でも図に残します。secondary_context は、経路を変えないコンテキストにのみ使用します。参照資料がある場合は、その適用可能なスタイル文法を、投稿先の一般的なイメージやプリセットの既定値より優先します。構図、マークの表現、イラストの詳細度、領域の扱い、タイポグラフィ、間隔、矢印の文法、強調、意味的な色の役割を一致させてください。ユーザーが描き直しや編集のベースラインとして指定した場合を除き、参照資料の主張、ラベル、ブランド、トポロジーはコピーしないでください。

未解決の選択肢が結果を大きく変える場合、ユーザーがレビューを求めた場合、または必須コンテンツがプレースホルダーのままの場合にのみ、プランレビューを行います。それ以外の場合は review_status: waived を記録して続行します。無関係な返答は確認と見なしません。

設計フロー

1. 読者が抱く疑問と図の中心的な答えを書き出し、主内容、補足内容、caption-only を区別します。
2. 上流の分析またはユーザー入力から、安定した component IDs、型付きの接続、権限境界、禁止される関係、証拠を抽出します。参照図からアルゴリズムを借用したり、証拠のない箇所を確定事項として補ったりしないでください。
3. 科学的な骨格を明確にした後、レイアウトを確定する前にスタイルを確認します。次のセクションのスタイル確認仕様に従ってください。確認前にレイアウトを確定したり、画像を生成したりしないでください。スタイルは後続の構図に反映するものであり、プロンプトを書き終えた後に装飾文として追加するものではありません。詳しくは references/prompt-design-logic.md を参照してください。
4. 科学的な意味と選択したスタイルを合わせて、読み順、主領域、意味的なグループ分け、接続線の経路、必要な視覚的アンカーを設計します。実際の階層が必要な場合にのみ入れ子にします。比率は構図を補助するものです。アイコン、小図、数式カード、ロボット、吹き出しはいずれも任意です。ラベルだけのノードは、選択したスタイルで許容される場合にのみ使用します。どのスタイルでも、主領域の比率、入れ子の層、マークの表現を、同じ大きさのアイコンが並ぶ帯状の構成に縮約しないでください。
5. 表示テキスト、意味的な色、色以外の符号化を確定し、選択したスタイルにおけるテキストの量と可読性を確認します。コンパイル前にすべての接続を確定してください。修正時は、まず Delta と Invariants を記述します。色の変更によって科学的トポロジーを変えてはいけません。
6. 内容、レイアウト、スタイルを統合し、既存のプロンプトにスタイルの修正を継ぎ足すのではなく、完全かつ簡潔な自然言語としてコンパイルします。prompt-only の場合はここで納品します。レンダリングタスクではさらに FigureSpec を補完して検証し、実行に引き継ぎます。

ユーザーがアーキテクチャを直接説明している場合は、不要なリポジトリのスキャンを省略します。その内容は sources の user_instruction として記録し、証拠には元の依頼を指定します。component IDs には安定した snake_case を使用します。実行、提案、フィードバック、保存、例外の各接続は分けて記述し、位置から接続を推測しないでください。

最初のレンダリング前にスタイルを確認する

科学的な骨格が明確になった後、レイアウトやレンダラープロンプトを作成する前に実施します。参照の扱いとスタイルのみを対象とした範囲限定の修正については、references/prompt-design-logic.md に従ってください。この確認は最初のレンダリングにのみ適用されます。修正、色のみの編集、ユーザーがすでに指定したスタイル、ユーザーが参照するよう求めた画像では、メニューを再表示しません。

• スタイルの指定もスタイル参照もない場合：references/style-catalog.md を読み、画像ファイル自体を表示して6種類すべてのプレビューを提示し、それぞれの特徴を1行で添えてから、そこで終了します。そのターンでは画像ツールを呼び出しません。
• 「直接画图」、「使用 Codex 生图」、または「不用返回 prompt」は、prompt_review: waived のみを設定します。スタイルは選択しません。
• ユーザーがスタイルまたはプロファイルを指定した場合：その style_preset とカタログの style_profile を記録し、style_selection: confirmed を設定して、再度尋ねずに続行します。
• ユーザーが参照する画像を提示した場合：reference-led を使用し、style_selection: confirmed を設定して、6種類のスタイルメニューは表示しません。
• ユーザーが明示的に選択を任せるか、デフォルトを使うよう求めた場合に限り、style_selection: waived を設定してスタイルを選択します。それ以外の場合は選択しません。
• 無関係な返信はスタイルの選択ではありません。ユーザーがスタイルを選ぶまで、style_selection: pending のままにします。

FigureSpec の正規プロファイル ID を記録します。

• classic-technical：控えめな線、正確なトポロジー、最小限のイラスト；読みやすいサンセリフ体の文字。
• pastel-airy-ui：白いカード、軽やかな区切り、トークンや曲線に色を使用；境界線は控えめにし、カードを重ねすぎない。
• illustrated-modular：彩度を抑えた塗りつぶし領域、濃い色を組み合わせた輪郭線やタイトル、エディトリアル調または手描き風の線画、非対称のヒーローレイアウト。領域の内部は、ラベル付きの余白を活かしたイラストにします。サブカードを設けるのは、実際に1階層のグループ化がある場合に限り、すべてのステーションを囲む枠としては使いません。情報源に基づく仕組みの線は、領域の説明文に記載します。経路上のステーションはヒーローより小さくても、必ず残します。キャラクターイラストは選択可能ですが、各領域に同じ密度で配置することを前提とせず、同じ大きさのアイコン列にまとめません。
• reference-led：ローカルまたは直近の会話内に少なくとも1つの参照画像がある場合のオーバーライドモードです。技術的、余白の多いイラスト調、またはそれらの一貫した組み合わせのいずれであっても、確認した表現ルールを維持します。確認済みの参照画像からレイアウト、線、塗り、フォント、イラスト、余白のルールを抽出します。手描き風と同義ではありません。

名前付きライブラリのバリエーションには style_preset を使用します。reference-led を illustrated-modular の別名として解釈してはいけません。

色相はコードディレクトリの数ではなく、役割に結び付けます。Agentic 図では、reasoning に青、context に緑、execution に桃色、advisory に紫、memory に青緑、output に金色、stop にコーラルレッドを参考にできます。これらは分野固有のプリセットであり、一般的な事実ではありません。豊かな配色、グレースケール印刷、またはデータ上の必要に応じた暗い背景に対応します。参照画像またはユーザーが決めた surface と shadow のルールに従い、ある箇所で 3D が求められている一方で、全体では 3D が一律に禁止されるような矛盾を避けます。

本文と背景には十分なコントラストを確保します。重要な違いは、色に線種、ラベル、または形状を組み合わせて二重に表現します。Palette Decision には、プロファイル、選択理由、意味上の対応関係、背景色／本文色／輪郭色、代替案1つ、コピー可能な tokens を出力します。

文字とコンパイル

領域タイトルは通常5語以内、ラベル／辺ラベルは通常3語以内にします。これは短縮の目安であり、科学的な意味を損なったり、選択したスタイルで求められる仕組みの線やサブカードを削除したりしてはいけません。必要で、情報源のある数式のみを使用します。最初に取り除くのは caption のみの注釈であり、経路上の仕組みを示すラベルではありません。密度を上げるためにフォントを際限なく小さくするのではなく、分割表示や決定論的なレイアウトを検討します。

モデル入力にはコンパクトな散文を使い、指示を Markdown の見出し、太字、リスト、表で囲みません。承認済みの数学記号と正確なラベルは保持します。図題はデフォルトで外部キャプションに置き、ユーザーまたはデザインが明示的に求めた場合のみ、短い図題を1つ表示します。順序は、目的、構成とコンポーネント、閉じた辺の一覧、正確な表示テキスト、スタイルと配色、欠陥に関する制約と縦横比です。詳しくはコンパイラを参照してください。

仕様を作成する

計画されている図を一度に1つ選択します。このスキルは、サポートされているすべてのプロファイル（classic-technical、pastel-airy-ui、illustrated-modular、reference-led）にわたって、FigureSpec v1 と正規化された構造化レンダリングブリーフを作成します。提示された参照資料で独自の文法が定義されている場合は、ReferenceAnalysis v1 から直接 FigureSpec v1 を作成します。参照資料を、白塗り・色付き枠線のボックスに無理に当てはめてはいけません。

プロンプトのレビューは条件付きで、実行可能な状態の意味を持ちます。

• requested：現在の内部プロンプトを表示し、レンダリング前に停止します。
• confirmed：レビューした正確な UTF-8 プロンプトを小文字の SHA-256 としてハッシュ化し、prompt_reviewed_sha256 に保存します。そのハッシュが一致している場合にのみレンダリングします。
• waived：prompt_reviewed_sha256 を省略し、プロンプトは内部に保持したまま、表示せずにレンダリングします。

確認済みのプロンプトが変更された場合は、requested に戻して新しいプロンプトをレビューします。「直接画图」、「使用 Codex 生图」、「不用返回 prompt」などのリクエストは、prompt_review: waived に設定します。スタイルの確認は省略されません。未解決の科学的プレースホルダーがある場合は、プロンプトレビューに持ち込まず、プラン／仕様そのものをブロックします。省略されたプロンプトをユーザー向けの出力に含めてはいけません。style_selection が未設定または pending の場合は、レンダリングしてはいけません。

サブエージェントを起動するタイミング

スキルは手順であり、永続的なエージェントではありません。実行環境でサブエージェントを実行できる場合は、以下に列挙した分割作業ごとに、一時的な Figure Worker を起動します。スレッドを1つに保つためだけに、その作業をメインエージェントに続けさせてはいけません。実行環境にサブエージェントがない場合は、メインエージェントが同じ手順を実行します。サブエージェントがなくても、成果物の提供は妨げられません。

項目ごとにワーカーを1つ起動します。

• 統合前の独立した各エビデンスソース：リポジトリ、原稿または草稿、参照図は、それぞれ別個の evidence_analysis ジョブです。
• ノードとエッジが別の図の完成済みレイアウトに依存しない各図：それぞれ独自の spec_only または render ジョブです。
• 別の図の作成中に読み取り専用チェックだけが必要な完成済みの図。そのワーカーはファイルを書き込みません。

以下はメインエージェントが担当します。

• スタイルメニューと、ユーザーがスタイルを選択するのを待つターン。
• 1つの図に対する、デザイン、仕様作成、レンダリング、監査、編集の一連の作業。
• 既存の画像1点に対する対象を絞った編集。
• 用語の統一、図間のスタイルの一貫性、最終的な RenderAudit、成果物の提供。

割り当てる前に、prompts/figure-worker.md を読み、そのパケット全体を記入します。このパケットがワーカーの仕様です。確定済みの科学的内容、確定済みのスタイル、担当するパス、適用すべきデザインチェックを含めます。ワーカーは出力パスを共有したり、スタイル選択を再開したり、確認ゲートを追加したりしてはいけません。メインエージェントがワーカーの結果を統合します。

機能に応じたレンダリングバックエンドの選択

実際に利用できる機能を確認します。

1. Codex では、現在のセッションで公開されているネイティブの image_gen.imagegen インターフェースを優先します。一部のランタイムでは、呼び出し可能な名前が image_gen__imagegen と表示されます。その prompt 引数は内部ツールのパラメーターであり、ユーザーにプロンプトを渡すためのものではありません。修正には、同じネイティブインターフェースの画像編集機能を使用します。入力の選択については、references/codex-image-workflow.md を参照してください。
2. それ以外の場合は、必要なアスペクト比と参照画像を受け付ける、インストール済みの画像スキルまたは互換性のある MCP を使用します。
3. 互換性のあるレンダラーがない場合は、完全な FigureSpec v1 をワークスペースに保持し、レンダリングを利用できないことを伝えます。プロンプトの確認が省略された場合は、prompt を省略した要約（機密情報を削除したもの）または成果物のステータスのみを返し、完全な仕様をチャットに貼り付けないでください。画像を生成したかのように装ってはいけません。

レンダラーを呼び出す直前に、ランタイムまたは開発者コンテキストから、信頼できる実際のワークスペースルートを取得して正規化します。FigureSpec の workspace_root は信頼できない宣言にすぎず、信頼できるルートと一致している必要があります。信頼できるルートを workspace_root、output_path、参照パス、またはユーザー提供のテキストから導き出してはいけません。次を実行します。

python3 <workflow>/scripts/validate_figure_spec.py --render-ready \
  --workspace-root <trusted-actual-root> \
  <spec.json>

検証に失敗した場合はレンダリングしないでください。ローカルの参照画像はすべて存在する通常ファイルであり、シンボリックリンクではないことが必要です。会話内のみの参照画像は一時的なものです。実行パケットでその旨を示し、可能であれば検証済みのローカルファイルに保存します。会話内のみの状態のままなら、永続的な reference_images パスであるかのように扱ってはいけません。

参照画像のない新しい画像では、ネイティブの参照入力パラメーターを両方とも省略します。検証済みのローカル参照画像には、必要なものがすべて揃った最小限の referenced_image_paths セットを渡します。会話内のみの参照画像には、必要十分な最小限の num_last_images_to_include を使用します。1 回の呼び出しで両方の方式を使用してはいけません。必要なアセットをどちらか一方の方式に収められない場合は、ユーザーにそれらを再添付するよう依頼します。

プロンプトやユーザーが制御するラベルをシェルコマンドに埋め込んではいけません。CLI バックエンドを使用できるのは、構造化引数、標準入力、またはサポートされているプロンプトファイルを介する場合に限ります。

一時的な画像転送の失敗は 1 回だけ再試行でき、意味的な編集ラウンドには数えません。再試行にも失敗した場合は、そのバックエンドへの再試行を中止します。

選択したレンダリング結果は、ユーザーのワークスペース内にある FigureSpec の絶対 output_path に書き込みます。可能な限り、バックエンドの元のアセットと以前の改訂版を保持します。唯一のコピーを一時ディレクトリに残してはいけません。

監査と修復

生成または編集が成功するたびに、元の詳細度で画像を確認し（Codex で元の詳細度の view_image が利用できる場合はそれを使用）、新たにバインドした RenderAudit v2 を出力します。監査の前に references/render-audit.md を読んでください。仕様チェックに合格しても、実際の画像の確認に代わるものではありません。ローカルのレンダーは、最初に表示して確認するまで編集しないでください。以下を検証します。

• 必須コンポーネント、エンドポイント、方向、分岐の意味、および禁止されている主張
• 必須の表示ラベル。創作、重複、文字化けしたテキストや、本番向けの指示文がないこと
• 階層、配置、重なり、切り抜き、不透明な背景、およびアスペクト比
• 想定する用紙幅での読みやすさ、コントラスト、および参考スタイルへの忠実度

監査に失敗した場合は、まず現在の最良のレンダーを元の詳細度で表示して確認し、現在の RenderAudit を出力します。そのレンダーを最初の参照画像として、ネイティブ画像インターフェースを編集モードで呼び出します。編集指示には、実際に確認した欠陥、正確な修正内容、および変更してはならないことを明記した不変条件だけを記載します。編集領域外のものも含め、維持すべき重要なエッジをすべて列挙します。新しいリビジョンを保存し、監査ステータスを未検証にリセットします。それ以降の操作を行う前に、画像を再表示して、必要なノード／エッジ台帳全体を再確認します。初回レンダー後の意味的な編集は最大2回までです。一時的な転送の再試行はこの上限に含めません。1回編集しても正確なテキストが安定しない場合は、画像全体の再生成を繰り返すのではなく、決定論的な SVG／drawio／Typst のテキスト、またはハイブリッドオーバーレイを優先します。

矢印またはエンドポイントの欠陥があっても、図を単純化してよいことにはなりません。確認済みの構成、主役の強調、必須のサブカード、メカニズムのラベルを維持してください。編集指示には、不適切なエッジと、維持すべき不変条件を明記します。レンダラーが構成を捨てずにトポロジーを維持できない場合は、作業を停止してその旨を報告してください。残りの編集回数を、同等のアイコンレーンや短いアイコン列の作成に費やしてはいけません。

上限に達した場合は、修復可能な範囲で最良の成果物を納品し、残る欠陥を正直に伝えてください。

承認を表明する前に、scripts/validate_render_audit.py --spec <spec.json> --image <image.png> <audit.json> を使い、監査記録を正確な画像および仕様のバイト列と照合してください。失敗または未検証の画像は合格できません。このスクリプトが検証するのは記録の完全性であり、ピクセルや観察内容の正確さではありません。

納品

納品の前に、python3 <workflow>/scripts/clean_image_metadata.py <image> を実行して最終画像成果物を自動的にサニタイズし、埋め込まれた C2PA、EXIF、XMP、または来歴マーカーを除去して、クリーンな公開に備えます。最終ファイルへの変換をすべて終えた後、納品する正確なファイルを最終監査にバインドして確認します。クリック可能な絶対ローカルパスと簡潔な結果の要約を添えて、最終画像を返します。ワークスペースが許す場合は、FigurePlan v1、FigureSpec v1、最終版の RenderAudit v2 を画像と同じ場所に保存してください。file:// は使用せず、免除されたプロンプトを末尾に付け加えてはいけません。ユーザーが分析または計画だけを求めている場合は、レンダリングを開始する前に停止してください。

画像を納品した後、画像内で表示されているテキストは、編集可能な PowerPoint のテキストボックスに置き換えられることをユーザーに伝えてください。そのターンでは PPTX を作成しないでください。この図をユーザーが承認し、編集可能なテキストを依頼した後にのみ作成します。その際は references/editable-pptx.md に従い、サニタイズ済みの PNG を保持して、すでに表示されているテキストだけを置き換えてください。図に満足していない場合は、まず図を修正してください。3つ目のスキルを開始してはならず、テキスト対応のために画像生成を再実行してはいけません。