slides-polish

スライドの仕上げ：ページごとの Codex レビューと対象を絞ったレイアウト修正

各レビュー枠の前に、選択可能なレビュアーに従ってください。 呼び出し元 → .aris/reviewer.json → Codex のデフォルト（新規のネイティブレビュアー）の順に解決し、 正規のヘルパーリゾルバーを通じて reviewer_route.py を使用します。その際、 この枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持してください。 以下の Codex の例や固定指定は、backend=codex の場合に限り適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約に従ってください。ルートと実際に返された識別情報を保存してください。 選択したレビュアーを利用できない場合は REVIEW_UNAVAILABLE です。実際の ファミリー／完了状況／スコープに基づいて受け入れを判定してください。レビュアーを使用する子プロセスには、 呼び出し元のレビュアー／モデル／処理負荷の上書き指定を引き継いでください。生成ワーカーに変更はありません。

生成済みのスライドデッキ（Beamer（.tex + .pdf）および／または PPTX）を、 参照ビジュアルに照らしたページごとの Codex レビューと、的を絞った修正（フォントの拡大縮小、テキストフレームのサイズ変更、コールアウトボックスのスタイル、エムダッシュの間隔、匿名化用プレースホルダー、中国語フォントのヒント、イタリック体のスタイル漏れ）を行い、 各スライドの視覚的な重みが参照と同じになるまで仕上げます。

仕上げ対象：$ARGUMENTS

このスキルの役割と対象外

**このスキルの対象は、レイアウトとタイポグラフィの仕上げのみです。**既存のデッキに対して、生成後に行う視覚的な調整です。

厳守するスコープルール（重要事項です。ハード不変条件を参照してください）。

• 内容、主張、数値、引用、URL、著者名、所属、実験結果は書き換えません。
• ユーザーから明示的に依頼されない限り（例：— add-slide / — drop-slide フラグ）、スライドの追加、削除、並べ替えは行いません。
• 論文のソースからアウトライン、発表者用スクリプト、新しい Beamer／PPTX を生成することはありません。それは /paper-slides の役割です。
• 図や数式の内容は変更しません。

まだデッキがない場合は、まず /paper-slides を実行してください。内容を変更したい場合は、/paper-slides のフェーズ 1～2 に戻るか、アウトラインを手動で書き直してください。そのために /slides-polish を実行してはいけません。

定数

• REVIEWER_MODEL = gpt-6-astra — ページごとのレビューに使用する Codex MCP モデルです。xhigh 推論は必須です（../shared-references/effort-contract.md を参照）。アカウントに gpt-6-astra の利用権限がない場合は、../shared-references/reviewer-routing.md に記載された正式な機能フォールバックチェーンに従ってください（モデルのフォールバックは gpt-6.1-sol+xhigh から始まります。gpt-5.4 はユーザーが明示的に指定した場合のみ使用します）。
• REVIEWER_REASONING = xhigh — 変更不可の不変条件です。推論の強度を指定する設定を変更しても、これは変わりません。
• CONTEXT_POLICY = fresh — ページごとのレビューでは、毎回新しい Codex レビュアー呼び出しを使用します（send_input は使わず、spawn_agent を使用します）。../shared-references/reviewer-independence.md を参照してください。これにより、レビュアーが過去の修正に引きずられるのを防ぎます。
• REFERENCE_VISUAL — ユーザーが、仕上げたスライド資料の視覚的な重み（タイポグラフィの比率、色使いの節度、コールアウトの密度）を合わせたい PDF のパスです。必須入力です。PPTX のみを仕上げる場合は、同じ講演の Beamer コンパイル版が理想的なリファレンスです。まだリファレンスがない場合はユーザーに確認してください。「Why-RF」やその他のプリセットを黙って既定値にしないでください。
• STYLE_PRESET = generic — デフォルトのスタイル基準です。その他の選択肢：why-rf（2025年の学術講演をもとにした、学術的でミニマルなスタイル）、neurips、icml、iclr、cvpr。プリセットは色使いの節度と要素ライブラリに影響しますが、視覚的な正解となるのはプリセットではなくリファレンス PDFです。
• PPTX_SCALE_HINT = 1.6× — 16:9、13.33"×7.5" の PowerPoint で視覚的な重みを合わせるために、Beamer のポイントサイズに掛ける目安の倍率です。範囲は 1.5～1.8× です。実際の倍率は、決してそのまま適用せず、必ず視覚的なレビューで検証します。
• INTERACTIVE = false — false の場合は、推奨される修正を自動で適用して次のスライドに進みます。true（— interactive）の場合は、修正ごとにユーザーの確認を待ちます。
• OUTPUT_VERSIONING = on — 出力は <input-stem>_polished.<ext>（または _polished_v2、_v3 など）という名前のバージョン管理されたファイルです。入力のスナップショットは <input-stem>_pre_polish.<ext> として保持されます。**元のファイルが上書きされることはありません。**すべての編集操作は _polished の作業用コピーを対象とします。

💡 上書き指定の例

• /slides-polish talk_pptx/talk.pptx — reference: talk_beamer/main.pdf — style: why-rf
• /slides-polish talk_beamer/ — reference: ./reference_talk.pdf — style: generic — effort: max
• /slides-polish talk.pptx — reference: ./why_rf_2025.pdf — interactive

前提条件

このスキルは Phase 0 で前提条件の不足を検出して報告します。自動インストールは行いません。必要なもの：

• Python：python3 と python-pptx>=0.6（pip install python-pptx）。
• PDF の確認：スライドを PNG にレンダリングするための pdfinfo と、pdftoppm（poppler、推奨）または mutool draw（mupdf）のいずれか。ページごとの Codex 呼び出しがテキスト抽出だけでなく、実際のスライド画像を確認するために必要です。レンダリングコマンド：pdftoppm -r 150 -png <pdf> <out-stem>（または mutool draw -o <out-stem>-%d.png -r 150 <pdf>）。
• PPTX → PDF のレンダリング：soffice（LibreOffice のヘッドレスモード）が推奨です。利用できない場合は、ユーザーが PowerPoint/Keynote から手動で PDF に書き出す必要があります。
• LaTeX（Beamer のみ）：xelatex（CJK）または pdflatex と、クリーンな再コンパイルに必要な latexmk。Phase 2 の Beamer 修正パターンでは、次の LaTeX パッケージが必要になる場合があります：microtype（セクションラベルの字間調整）、array（左揃えの p 列）、tcolorbox（バナーとコールアウト）、ctex または xeCJK（CJK）、tikz + tikz-cd（図）。
• 選択したレビュアー：Phase 0 の前にルートを解決してください。利用できない場合は REVIEW_UNAVAILABLE で停止し、別のプロバイダーを黙って選択しないでください。ページごとの視覚レビューを行うには、画像/PDF 入力機能が要件を満たしている必要があります。

フォールバックのルール：

• pdftoppm/mutool が見つからない場合 → ユーザーにインストールを依頼し、処理を続行しないでください（ページをレンダリングせずに視覚レビューを行うと、Codex からのフィードバックの信頼性が低くなります）。
• soffice が見つからず、入力が PPTX の場合 → ユーザーにスライドツールから PDF を書き出すよう依頼し、その後に再開してください。

入力

$ARGUMENTS とプロジェクトディレクトリから自動的に検出されます。

1. スライドのソース：
   • *.pptx を含むディレクトリ、または talk_beamer/main.tex + main.pdf、あるいはその両方。
   • 特定のファイルパス（talk.pptx または main.tex）。
2. 参照 PDF（— reference: <path>、必須）。指定されていない場合、スキルはユーザーに確認します。黙って代替ファイルを使わないでください。
3. スタイルプリセット（— style: <preset>、デフォルトは generic）。色の HEX コードと要素ライブラリに影響します。「スタイルプリセット」を参照してください。
4. 作業量（— effort: lite | balanced | max | beast、デフォルトは balanced）。「作業量レベル」を参照してください。
5. インタラクティブフラグ（— interactive）。各スライドの修正後に一時停止します。

出力レイアウト

<deck-dir>/
├── <stem>.pptx                       # original (untouched)
├── <stem>_pre_polish.pptx            # snapshot before any edit
├── <stem>_polished.pptx              # versioned working output
├── <stem>_polished.pdf               # rendered (when conversion available)
└── ... (Beamer files mirrored)

.aris/slides-polish/<deck-stem>/
├── POLISH_STATE.json                 # phase + per-slide status + version pointer
├── INSPECT_<stem>.json               # pre-polish shape inventory
├── TRIAGE.md                         # Phase-1 verdict matrix (per-slide PASS/NEEDS-WORK/BLOCKER)
├── POLISH_CHANGELOG.md               # per-slide fix log (auditable)
└── traces/                           # codex traces (per-slide review JSON, see review-tracing.md)
    ├── slide_01.json
    ├── slide_02.json
    └── ...

このスキルは、自己完結型のキャッシュを .aris/slides-polish/<deck-stem>/ に保持します。呼び出しごとの Codex トレースも、共有規約 .aris/traces/slides-polish/<date>_runNN/ に従います（../shared-references/review-tracing.md を参照）。"status": "in_progress" かつ 24 時間未満の POLISH_STATE.json が存在する場合、セッションをまたいで再開できます。

注：/paper-slides など既存のスキルでは、同じディレクトリに状態ファイルを置く場合があります（例：slides/SLIDES_STATE.json）。/slides-polish は、スライドのディレクトリに仕上げ専用の不要ファイルを残さないよう、状態ファイルを .aris/ に保持します。

ワークフロー

フェーズ 0：一覧作成、検査、トリアージ

1. 入力を検出：$ARGUMENTS を解析し、スライドファイルを探して前提条件を確認し、簡潔な一覧レポートを出力します。
2. 参照 PDF を確認：ファイルの存在と、入力とスライド数が一致すること（または少なくともスライド数以上であること）を検証します。不一致がある場合はユーザーに確認します。
3. 図形を検査：インスペクターを実行し（以下のフェーズ 0 のサブステップを参照）、すべてのスライド上の各テキストフレームと図形を列挙した INSPECT_<stem>.json を生成します。含める情報は、図形 ID、種類、テキスト内容（エスケープ済み）、実行ごとのフォントサイズ、インチ単位のバウンディングボックス、塗りつぶし色／線の色、画像の寸法、発表者ノートの有無です。このファイルを、後続工程での「テキストによる図形の検索」の信頼できる基準とします。
4. 元ファイルをスナップショット：cp <stem>.pptx <stem>_pre_polish.pptx を実行します（Beamer がある場合は .tex も対象）。以降の編集はすべて _polished コピーに対して行います。
5. 必要に応じて PPTX を PDF にレンダリング（soffice --headless --convert-to pdf）。利用できない場合は、ユーザーにエクスポートを依頼します。
6. PDF を PNG にレンダリング：pdftoppm -r 150 <pdf> .aris/slides-polish/<stem>/png/page を実行し、スライドごとに PNG を 1 枚生成します。ページごとのレビュー時に Codex に渡します。
7. トリアージ：新規の Codex 呼び出しを 1 回行い、PPTX の PDF（または Beamer PDF）と参照 PDF を比較して、全 N 枚のスライドを確認します。出力はスライドごとの判定マトリックスです。

インスペクターの仕様

このスキルでは、固定実装ではなく inspect_pptx.py の仕様を定めています。**初回実行時に .aris/slides-polish/<deck-stem>/inspect_pptx.py にスクリプトが存在しない場合は、この仕様に基づいて作成してください。**実装は変更される場合がありますが、後続フェーズが依存するのはこの仕様です。

CLI：

python3 inspect_pptx.py --pptx <input.pptx> --out <state-dir>/INSPECT_<stem>.json
# exit 0 on success, 2 on missing python-pptx, 3 on parse failure

グループを再帰的にたどり、表のセルとプレースホルダーを抽出します。すべてのジオメトリを EMU_PER_INCH = 914400 を使って EMU からインチに変換します。フェーズ 4 でバイト単位の整合性を確認できるよう、notes_text_hash は sha256(notes_text) として計算します。スキーマ：

{
  "slide_count": 22,
  "slide_size_in": [13.33, 7.5],
  "slides": [
    {
      "index": 0,
      "page_number_text": "1 / 22",
      "has_notes": true,
      "notes_text_hash": "sha256:…",
      "shapes": [
        {
          "id": "13",
          "name": "TextBox 3",
          "shape_path": ["13"],
          "parent_group_ids": [],
          "type": "TEXT_FRAME",
          "placeholder_type": null,
          "table_cell": null,
          "text": "ARIS",
          "runs": [
            {"text": "ARIS", "font_pt": 80.0, "bold": false,
             "italic": false, "color_rgb": "1F1F1F"}
          ],
          "bbox_in": {"left": 0.5, "top": 1.6, "width": 12.33, "height": 0.95},
          "fill_rgb": null,
          "line_rgb": null,
          "image_size_px": null
        }
      ]
    }
  ]
}

スキーマに関する注記：

• shape_path：最外部のグループからリーフ図形までの図形 ID のリストです。
• parent_group_ids：図形がスライドのルートにある場合は空です。
• type：TEXT_FRAME | PICTURE | AUTO_SHAPE | GROUP | TABLE | CONNECTOR | PLACEHOLDER のいずれかです。
• placeholder_type：例：TITLE | BODY | OBJECT | NONE。
• table_cell：図形が表のセルである場合は {row, col}、それ以外は null です。
• すべての HEX カラーは、先頭に # を付けない大文字 6 文字です。
• すべてのジオメトリはインチ単位で、小数点以下 4 桁に丸めます。

トリアージ用 Codex プロンプト

まずこのレビュースロットを解決してください。以下は backend=codex の例です。

spawn_agent:
  model: gpt-6-astra
  reasoning_effort: xhigh
  message: |
    Triage pass. For each of N slides in <pptx-pdf-path>, compared against
    <reference-pdf-path>, give one line:

      Slide K | PASS | NEEDS-WORK | BLOCKER — <one-sentence reason>

    Focus on: visual-weight match, text-frame overflow, page-number overlap,
    awkward title wraps, italic style leaks, Chinese tofu/missing-glyph
    boxes, callout-box color discipline, anonymity leaks (e.g., real titles
    appearing where placeholders should be).

    Do NOT rewrite content. Do NOT propose font scaling for slides that
    already read fine. Do NOT comment on speaker notes.

    End with a one-line summary: "K BLOCKERS, K NEEDS-WORK, K PASS."

マトリックスを TRIAGE.md に保存します。詳細な作業を始める前に、ユーザーに提示してください。

Phase 1：ページごとのレビューと修正ループ

NEEDS-WORK または BLOCKER のフラグが付いたスライドごとに、新しいスレッドで Codex を呼び出し、対象を絞ってレビューします。返された修正をすぐに適用し （INTERACTIVE に従います）、再コンパイルまたは保存してから、次のスライドに進みます。

一括ではなく、ページごとにループします。 実際の検証では、ページごとに Codex を呼び出すと 1～2 回の仕上げで収束しますが、1 回でまとめてレビューする方法では収束しません。

ページごとの Codex プロンプトテンプレート

まずこのレビュースロットを解決してください。以下は backend=codex の例です。

spawn_agent:
  model: gpt-6-astra
  reasoning_effort: xhigh
  message: |
    SLIDE K review. Compare PPTX page K against reference page K.

    Files:
    - PPTX page rendering: <png-path>/page-K.png
    - Reference page rendering: <ref-png-path>/page-K.png
    - Source: <pptx-file-path> (slide index K-1) and/or <main-tex-path>
    - Inspector inventory for slide K: <inspect-json-slide-K-snippet>

    Slide K title (from inventory): "<title>".

    Style anchor: <style-preset> + reference PDF.

    Give:
    1. Status: PASS / NEEDS-WORK / BROKEN
    2. What's working (1-2 specifics)
    3. What's drifting vs reference (1-3 specifics)
    4. Concrete python-pptx (or .tex) fixes:
       - Identify shapes by their text content (NOT by index — index drifts).
       - Use unique-prefix substring matching; if duplicate matches, abort
         and request human disambiguation rather than touching the first.
       - Give before/after snippets.
    5. If a fix would change CONTENT (claims, numbers, anonymity placeholder
       text, etc.), STOP and report it instead of suggesting it.

    End: VERDICT: PASS | NEEDS-WORK | BROKEN. Under 500 words.

修正の適用

Codex から返答があったら、apply_fix(slide_index, fix_block) を呼び出します。処理内容は次のとおりです。

1. _polished 作業用コピーを読み込みます。
2. text_frame.text の部分文字列で対象の図形を特定し、一致が一意であることをアサートします。一致が一意でなければ中止します。
3. 編集（フォントサイズ、位置、色、斜体、行間）を適用します。
4. アトミックに保存します（tmp に書き込んでから rename します）。
5. 変更内容を POLISH_CHANGELOG.md に記録します（1 行：Slide K | <change> | reason）。

3 枚処理するごとに、チェックポイントのスナップショット <stem>_polished_checkpoint_KK.pptx を書き出します。

堅牢な図形の選択

def find_shape(slide, contains: str, *, kind: str | None = None):
    """Return the unique shape whose text_frame.text contains `contains`.
    Aborts if duplicate matches (caller must disambiguate by bbox or kind).
    """
    matches = []
    for sh in slide.shapes:
        if not sh.has_text_frame:
            continue
        if kind is not None and sh.shape_type != kind:
            continue
        if contains in sh.text_frame.text:
            matches.append(sh)
    if len(matches) == 0:
        raise LookupError(f"no shape contains {contains!r} on slide")
    if len(matches) > 1:
        raise AmbiguousMatch(f"{len(matches)} shapes contain {contains!r}; "
                             f"need disambiguator (kind, bbox, or longer needle)")
    return matches[0]

グループ化された図形では、shape_type == GROUP の場合に shape.shapes を再帰的に処理します。

Phase 2：Beamer 側の仕上げ（Beamer ソースがある場合）

ページごとのレビュー方式は同じですが、対象は main.tex ソースとコンパイル済み PDF です。修正は main_polished.tex 作業用コピーに対して Edit ツールで直接行い、 xelatex で再コンパイルして PNG を再レンダリングします。元の main.tex は保持されます。

Beamer のよくある修正パターン（インラインカタログ — 外部ファイル不要）

これらは SKILL.md に直接記述されているため、このスキルに外部依存関係はありません。

• フレームタイトルのサイズと細い下線：beamercolorbox テンプレートを使い、 タイトルテキストの AFTER に \hrule height 0.55pt を配置します。beamercolorbox の外に 単独の \rule{} を置いてはいけません（タイトルの下ではなく、右上に描画されます）。
• 小型大文字の青いミニ見出し用 \sectionlabel マクロ：

  \newcommand{\sectionlabel}[1]{%
    {\sffamily\fontsize{8}{10}\selectfont
     \textcolor{<accent>}{\textls[200]{\MakeUppercase{#1}}}}}
  

  \textls を使うには microtype が必要です。
• カード内の >{\raggedright\arraybackslash}p{Xcm} には array パッケージ。 これがないと、表のセルが両端揃えになり、狭い列で不自然な空白や単語途中のハイフネーションが発生します。
• バナーには実際の tcolorbox を使用。\begin{center}\color{...} は バナーではなく、単なる中央揃えのテキストとして描画されます。
• 全角ダッシュの間隔：単独の — よりも、明示的な波括弧を付けた \textemdash{} または \,---\, を使います。単独の全角ダッシュでは、前後の空白が詰まって描画されることがよくあります。
• \sectionlabel 内の色漏れ：\sectionlabel{... \textcolor{red}{...}} は 機能しません。\MakeUppercase が色名を大文字に変換し、未定義色エラーが発生します。 \textcolor を外側に置くか、色付きの \sectionlabel* バリアントを定義してください。
• CJK と数式：xelatex では \usepackage[fontset=fandol]{ctex} を使うか、 EA フォントを明示的に設定します。タイトルに中国語と英語が混在する場合は EA フォントの ヒントが必要です。指定しないと文字がラテンフォントにフォールバックします。

Phase 3：PPTX 側の仕上げ

まずフォントを拡大し（Phase 3a）、その後レイアウト修正ループを実施します（Phase 3b）。 フレームのサイズを変更せずにフォントだけ大きくすると、はみ出しが発生します。

Phase 3a：フォントの拡大（ヒューリスティック表）

PPTX_SCALE_HINT を使って、Beamer の参照値から目標サイズを計算します。参照マッピングは次のとおりです。

Beamer pt	PPTX target	Role
8 / 8.5	14-18 小型大文字	セクションラベル
10 italic	14 italic	グレーの斜体キュー／ヒント
11 body	22-24	箇条書き、段落
12 ページ番号	16	右下のグレーの「N / total」（16 を上限とする）
14 強調本文	22-24	大きめの小見出し
16 コールアウトの内容	24-28	eqbox / yellowstrip の本文
17-22 大きな数値	28-36	主要な統計値（例：「8.1k+」、ファネル「8/6/2/1」）
22 フレームタイトル	40-44	すべてのページタイトル
28 強調ヒーロー	36-44	ヒーローテキスト
42 表紙のワードマーク	80-100 通常の BLACK	表紙（Why-RF の方針：色を付けない）

ページ番号のルール：ページ番号を 16pt より大きくしてはいけません。小さいままにします。

拡大後は、必ず Phase 1 のトリアージを見直してください。1.6× のヒントは出発点です。 スライドによっては 1.5×、別のスライドでは 1.8× が必要です。

フェーズ 3b：テキストフレームのレイアウト修正ループ

フォントサイズを上げた後によく発生する、次の 2 つの問題：

1. タイトルがサブタイトル／本文に重なる：100pt のタイトルが高さ 0.95" のフレームに配置されている一方、文字の高さは約 1.4" あるため、下にはみ出します。修正：テキストフレームの高さを増やし、次の要素の上端位置も調整します。
2. 本文の箇条書きが文の途中で折り返される：長い名詞句を含む箇条書きが折り返され、最後の名詞だけが次の行に残ります。これは、フレーム幅が以前の小さいフォントに合わせて設定されているためです。修正：フレームを広げ、隣接する列を狭めます。

ページごとの Codex 呼び出しで具体的な図形のサイズ変更コマンドが返されます。インスペクターの bbox プリミティブを使って適用してください。

フェーズ 3c：よくある PPTX の落とし穴（インラインカタログ）

• 画像のアスペクト比：height を指定せずに width を大きくすると、埋め込み PNG が引き伸ばされます。必ず height = width × (image_height_px / image_width_px) を計算してください。
• バナーは実際に塗りつぶされた長方形にする：色付きのテキストだけでなく、tcolorbox 相当のものを使用します（PPTX では、テキストフレームの背後に独立した MSO_SHAPE.RECTANGLE を配置します）。
• 曲線矢印：python-pptx に曲線矢印のプリミティブはありません。2 本の直線 MSO_CONNECTOR_TYPE.STRAIGHT コネクター（垂直＋水平）で近似するか、add_freeform のベジェ曲線を使用します。近似であることを記載してください。
• イタリック体のスタイル漏れ：ソース内で波括弧を使わずに \itshape を指定すると、同じ段落内の後続のすべてのランにもイタリック体が適用されます。{\itshape ...} で囲むか、単一のランに限定してください。
• 中国語のレンダリング：PowerPoint で中国語を表示するには、東アジアフォントのヒントが必要です（macOS では <a:ea typeface="PingFang SC"/>、Windows では Microsoft YaHei）。これがないと、文字がラテンフォントにフォールバックし、豆腐文字として表示されます。
• ダッシュの間隔：タイトル内の単独の — は、しばしば前後のスペースが詰まって表示されます。文字としてスペース（" — "）を挿入するか、図形スペースを使用してください。
• 循環矢印／フィードバックループのラベル：ラベルの bbox がスライドの境界内に収まるようにしてください（L > 0.4in、T > 0.4in）。PPTX はスライド外のコンテンツを警告なしにクリップします。左端や上端に近い位置に配置された曲線ラベルが、最もよく問題を起こします。
• 匿名性プレースホルダーの徹底：審査中の作業に関するすべてのプレースホルダーには、一般的な表現（例：「匿名審査のため非公開」、「[匿名化済み]」）を使用してください。実際のタイトル、件数、URL を推測したり補ったりしてはいけません。../shared-references/experiment-integrity.md を参照してください。

フェーズ 4：検証と再トリアージ

1. PPTX を PDF に再レンダリングします（LibreOffice またはユーザーによるエクスポート）。
2. PDF を PNG に再レンダリングして、見た目を確認します。
3. 再トリアージ：フェーズ 0.7 のプロンプトを再実行します。目標は BLOCKER 0 件、NEEDS-WORK 2 件以下です。NEEDS-WORK が 2 件を超えて残る場合は、該当するスライドについてフェーズ 1 に戻ります。
4. 発表者ノートの整合性チェック：各スライドの notes_slide が存在し、_pre_polish.pptx から変更されていないことを確認します（ポリッシュ処理でノートの内容を変更してはいけません）。
5. 匿名性スキャン：最終的な PPTX に、既知の機密文字列（元の資料には存在しない実際の著者名、LLM によって追加された実際の URL、実際の投稿件数）が含まれていないか grep します。見つかった場合は、フェイルクローズして報告します。
6. 最終出力：<stem>_polished.pptx（レンダリングした場合は .pdf も）。

フェーズ 5：変更履歴

POLISH_CHANGELOG.md を作成します：

Slide  1 cover  | bumped wordmark 80→86; subtitle 36→40; line spacing 0.9        | Codex per-page review
Slide  2 hook   | left body L=0.45 W=8.30; right cards 28→19pt; yellow strip 22→19 | wrap fix
Slide  3 …      | …                                                              | …

これにより、すべてのポリッシュ処理を監査し、元に戻せるようになります（各行は _polished_v{i} チェックポイントに対応します）。

スタイルプリセット

プリセットが影響するのはデフォルトの色と要素ライブラリのみです。視覚的な正解となるのは常に参照 PDFであり、プリセットではありません。

generic（デフォルト）

黒＋アクセントカラー 1 色（デフォルトは #2563EB）。重要な情報を示す場合を除き、コールアウトボックスの塗りつぶしは、単一の中立色の背景に限ります。

why-rf（academic-minimalist、サンプルプリセット）

基準：以下の規律に沿った、rectified flow に関する2025年の学術講演。

要素	Beamer	PPTX（1.6×の目安）	備考
フレームタイトル	\fontsize{22}{26}	40-44pt サンセリフ太字	全幅の細い0.55ptアクセント下線を追加
本文	11pt	22-26pt	Calibri／Helvetica Neue相当
カードタイトル（chorebox）	11pt 太字	20-26pt 太字	chorebox コールアウト内
セクションラベル	8pt スモールキャップ	16-18pt スモールキャップ、広めの字間	色＝メインアクセント
グレーのイタリック体の補足	\scriptsize\itshape	12-14pt イタリック体	色＝pagegray
ページ番号	\footnotesize	14-16pt	右下、グレー
表紙タイトル	44pt、装飾なしのBLACK	80-100pt、装飾なしのBLACK	タイトルに色は付けません

カラーパレット（重要な箇所にのみ、控えめに使用）：

• メインアクセント（例：#2E75B6）
• 濃いアクセント（チップの背景、大きな数字など。例：#1F4E79）
• 明るいコールアウト背景（例：#DEEBF7）
• 正直な開示用の黄色（例：#FFF4CC）
• 監査上のバグ用の赤（安全性に関する免責事項のみ。例：#C00000）
• ページグレー（例：#808080）
• ダークテキスト（例：#1F1F1F）

要素ライブラリ（控えめに使用）：

• chorebox：白い背景＋細い上部アクセント線＋セクションラベル＋太字タイトル＋本文
• eqbox：明るいアクセント色の全幅バナー。重要な前提／結論にのみ使用
• yellowstrip：正直な開示用の黄色＋左端に3ptのオレンジ線。正直な開示にのみ使用
• redbox：明るい赤色＋赤い枠線。安全性に関する免責事項にのみ使用
• banner：明るいアクセント色の全幅ストリップ。短いバナーキャプション

規律：一般的な「デザイナー風」テンプレートより、色付きボックスを少なくします。装飾目的のカードは通常の箇条書きに置き換え、マーケティング的な装飾は取り除きます。

neurips / icml / iclr / cvpr

配色は /paper-slides を継承します。仕上げの反復とフォントスケーリングのルールに変更はありません。

作業レベル

完全な仕様については ../shared-references/effort-contract.md を参照してください。

effort	動作
lite	トリアージを行い、BLOCKER のみを修正します。NEEDS-WORK のスライドはページごとのレビューを省略します。フルトークンコストの約30％です。
balanced（デフォルト）	トリアージに加え、NEEDS-WORK と BLOCKER のすべてのスライドをページごとにレビューします。PASS のスライドには手を加えません。
max	PASS を含むすべてのスライドをページごとにレビューします。トークン数は約2.5倍です。
beast	max に加え、Phase-4 の再トリアージ後に仕上げをもう1ラウンド行います。残っている2pt以下のはみ出しや軽微な折り返しを修正します。トークン数は約5倍です。

すべてのレベルで reasoning_effort: xhigh は必須です。

厳守すべき不変条件

以下は必ず守る必要があります。

1. 参照資料が必須です。 このスキルは、視覚的な基準が明示されていない状態で仕上げを行いません。参照PDFがない場合は、ユーザーに尋ねます。スタイルプリセットは代用になりません。
2. 元のファイルは上書きしません。 すべての編集は <stem>_polished.<ext> を対象とし、ロールバック先は <stem>_pre_polish.<ext> のスナップショットです。
3. 発表者ノートは一字一句そのまま保持します。 PPTXを編集する際は、必ず slide.notes_slide の内容を保持します。フェーズ4.4では、スナップショットとバイト単位で一致することを検証します。
4. コンテンツは編集しません。 新たな主張、数値、引用、URL、著者名、所属、実験結果を追加しません。数式や図の内容も変更しません。本文を言い換えず、スタイル、タイポグラフィ、ボックスの編集だけを行います。Codexの修正案がコンテンツを変更する場合、このスキルは停止してその旨を報告します。
5. スライドの並べ替え、追加、削除は行いません。ただし、ユーザーが明示的なフラグ（— add-slide-K-after-J、— drop-slide-K）を渡した場合を除きます。
6. 新しいコンテキストから独立して処理します。 ページごとのCodex呼び出しは send_input ではなく、新規の spawn_agent 呼び出しです。レビュー担当者は以前の修正リストを参照しません。ベース判定は同じファミリーによる暫定判定です。
7. 匿名化プレースホルダーは厳格に扱います。 プレースホルダーだった箇所に実際のタイトル、件数、URLを記入する修正案をCodexが提示した場合、このスキルはその案を却下し、人間による確認が必要な案として提示します。experiment-integrity.md を参照してください。
8. ページ番号は16pt以下にします。 Why-RFの規律に従い、決して大きくしません。
9. reasoning_effort: xhigh は、すべての effort レベルで不変です。
10. 堅牢な図形選択を行います。 編集では、一意であることをアサートするセマンティクスにより、text_frame.text の一意なプレフィックス一致を使用します。一致する項目が重複している場合は中止し、曖昧さの解消を依頼します。

レビューのトレース

ページごとのCodex呼び出しの後、../shared-references/review-tracing.md に従ってトレースを保存します。呼び出しごとのファイルは .aris/slides-polish/<stem>/traces/slide_KK.json とし、以下を記録します。

• Codex の agent_id
• プロンプト（原文のまま）
• 応答（原文のまま）
• 適用した差分の概要（編集した図形のサイズ／bboxの変更前と変更後を含むリスト）
• 検証ステータス（修正後の再レンダリングのPASS／FAIL）

トリアージの工程とスライドごとの工程の両方をトレースします。

既存スキルとの関係

• /paper-slides（または外部で生成されたデッキ）の後に実行します。
• /paper-poster-html ワークフローと互換性があります（同じ色の規律）が、出力のタイミングは異なります。
• /auto-paper-improvement-loop、/research-review などと同じ spawn_agent MCP インフラストラクチャを使用します。
• /paper-slides のコンテンツフェーズは呼び出したり組み合わせたりしません。厳密に分離されています。

使用しない場合

• スライドがまだコンテンツの草稿作成段階にある場合は、/paper-slides のフェーズ1～2に戻ります。
• 全面改訂（色、テンプレート、アスペクト比の変更）が必要な場合は、仕上げではなく /paper-slides を再実行します。
• デッキのスライドが5枚未満の場合は、ページごとのレビューにかかる手間に見合わないため、手作業で編集します。
• ユーザーが明示的に「Codexなし」と指定した場合、このスキルはCodex主導で設計されているため使用しません。

実証に基づく由来

このスキルは、中国語で行われた学術会議の講演（2026年5月）の仕上げ作業から抽出されました。収束した観察結果は次のとおりです。コンテンツが確定した後に残るコストは、ページごとの視覚的な忠実度です。具体的な python-pptx／.tex の修正スニペットを使うページごとのCodexレビューは、1～2ラウンドで収束しますが、単一パスの一括レビューでは収束しません。フェーズ2～3の修正パターンカタログ（Beamerテンプレートの注意点、PPTXのフォントサイズ調整、レイアウト修正ループ、中国語フォントに関するヒント）が、長く活用できる成果物です。

パラメーターの受け渡し

/research-pipeline または別のオーケストレーター経由で呼び出された場合、パラメーターは次のように渡されます。

• — effort → Effort Levels を参照してください。
• — reference → REFERENCE_VISUAL。
• — style → STYLE_PRESET。
• — interactive → INTERACTIVE = true。

その他の引数（例：— venue）はこのスキルでは無視され、引き継がれません。