table-schema

テーブルスキーマ（2層：インデックスと付録）

トリガーとルーティング

• トリガー：テーブルスキーマ、スキーマ優先のテーブル、テーブル設計、表格 schema、先 schema 后填充。
• 使用する場面：LaTeX に進む前に、検証可能で記入可能なサーベイテーブルが必要な場合（通常は Stage C4、エビデンスパックの作成後）。

テーブルは飾りではなく、情報を圧縮するものです。

このパイプラインでよくある失敗は、最初に生成されるテーブルが内部インデックスのように見えることです。 そこで、テーブルを次の2層に分けます。

1. outline/tables_index.md（内部用）

• 目的：網羅性の確認／デバッグと、エビデンスの素早い確認
• より網羅的な内容にしてもかまいません
• 論文に挿入してはいけません

2. outline/tables_appendix.md（読者向け）

• 目的：公開可能なサーベイテーブル（すっきりしたレイアウトと高い情報密度）
• 最終 PDF の付録として挿入できます

このスキルでは、記入を始める前に両方の層を設計します。

デフォルトモード：セマンティック（LLM 優先）

スクリプトを実行する作業ではなく、設計タスクとして扱います。

既存のエビデンスパックから推測なしで記入できない列がある場合、そのスキーマは適切ではありません。

役割（明示的に使う）

テーブル設計者（読者の視点）

ミッション：パイプラインに関する問いではなく、読者の疑問に答えるテーブルを選びます。

実施事項：

• 各テーブルが1つの疑問に答えるようにします
• 記入可能なサイズに収めます（難しい巨大なテーブル1つより、適切なテーブル2つが優れています）

避けること：

• 論文内に内部用／ログ形式のテーブルを置くこと
• このリポジトリ内でしか意味が通じない列ラベル

エビデンス管理者（記入可能性）

ミッション：事実の捏造を必要とするスキーマを認めません。

実施事項：

• すべての列を、具体的な上流フィールドに対応付けます
• 長い段落をセルに入れざるを得ない列は却下します

避けること：

• TODO 列
• プレースホルダー（"TBD"、"..."、"(placeholder)"）

ワークフロー（入力を明示）

• 読者の疑問とスコープを一定に保つため、GOAL.md を使います。
• queries.md:draft_profile が存在する場合は読み込みます。これはテーブルの数を決めるものであり、エビデンスの基準を変えるものではありません。
• テーブルの行単位を論文の構成に合わせるため、outline/outline.yml を使います。
• テーブルの次元／軸を承認済みの構成に基づかせるため、outline/subsection_briefs.jsonl を使います。
• 予定しているすべての列を推測なしで記入できることを確認するため、outline/evidence_drafts.jsonl を使います。

入力

• outline/outline.yml
• outline/subsection_briefs.jsonl
• outline/evidence_drafts.jsonl
• 任意：GOAL.md

出力

• outline/table_schema.md

必須要件（スキーマの仕様）

• draft_profile ごとの最小定義数：
  • course_paper：インデックステーブル1つ以上、付録テーブル1つ以上
  • survey / deep：インデックステーブル2つ以上、付録テーブル2つ以上
• 各テーブルの定義には、次の項目を含める必要があります：
  • 回答する問い
  • 行単位（H3／ベンチマーク／研究／失敗モード）
  • 列（セルのスタイル制約を含む）
  • エビデンスの対応付け（どの上流フィールドがどの列を埋めるか）
• セルのスタイル：短いフレーズを使い、段落形式のセルは避けます。
• 論文としての文体：付録テーブルのキャプション／列は、公開可能な表現にします（パイプライン用語は使いません）。

推奨デフォルト（arxiv-survey 系）

course_paper では、コンパクトなデフォルトとして I1 と A1 を使います。エビデンスが独立した読者の疑問を裏付ける場合に限り、I2 または A2 を追加します。survey と deep では、以下の I1／I2／A1／A2 の一式を使います。

インデックステーブル（table-filler → outline/tables_index.md）

I1）サブセクションマップ（軸＋代表的な研究）

• 行単位：H3
• 列：サブセクション；軸；代表的な研究
• エビデンスの出典：subsection_briefs.axes ＋ evidence_drafts からの引用

I2）具体的な根拠（ベンチマーク／数値／注意点）

• 行単位：H3
• 列：サブセクション；根拠となる事実；代表的な研究
• エビデンスの出典：anchor_sheet.anchors

付録の表（appendix-table-writer -> outline/tables_appendix.md 用）

A1) 手法/アーキテクチャのマップ（代表的な研究）

• 行の単位: 研究/システムの単位
• 列: 研究; 中核となる考え方; ループ + インターフェースの前提; 主要参考文献
• 根拠の情報源: evidence_drafts（比較 + 定義）+ anchor_sheet

A2) 評価プロトコル/ベンチマークのマップ

• 行の単位: ベンチマークまたは評価設定（代替: プロトコルの次元）
• 列: ベンチマーク/設定; タスク+指標; 主要なプロトコル制約; 主要参考文献
• 根拠の情報源: anchor_sheet + evidence_drafts.evaluation_protocol

良い例/悪い例

良い例（公表可能な問い + 埋められる列）:

• 問い: 「この領域の評価を支えているベンチマークはどれか、そしてそれらはどのようなタスク/指標/制約を意味するのか？」
• 列: ベンチマーク; タスク+指標; プロトコル制約; 主要参考文献
• 根拠のマッピング: evidence_drafts.evaluation_protocol + anchor_sheet

悪い例（内部/パイプラインの視点）:

• 問い: 「エビデンスの準備状況 + 検証の必要性はどうなっているか？」
• 列: エビデンスのレベル、不足フィールド、TODO チェックリスト

内部向けの診断が必要な場合は、読者向けの表ではなく監査レポートに記載してください。

スクリプト（任意のブートストラップ）

クイックスタート

• uv run python .codex/skills/table-schema/scripts/run.py --help
• uv run python .codex/skills/table-schema/scripts/run.py --workspace <workspace>

すべてのオプション

• --workspace <workspace>（必須）
• --unit-id <id>（任意; ランナーの記帳にのみ使用）
• --inputs <outline;briefs;packs;goal>（任意; 入力を上書き）
• --outputs <relpath>（任意; デフォルトは outline/table_schema.md）
• --checkpoint <C#>（任意; ブートストラッパーでは無視されます）

例

• 2 層スキーマ（インデックス + 付録）をブートストラップする:

  uv run python .codex/skills/table-schema/scripts/run.py --workspace <workspace>

• カスタムのスキーマパスに書き込む（まれ）:

  uv run python .codex/skills/table-schema/scripts/run.py --workspace <workspace> --outputs outline/table_schema.md

注記:

• スクリプトは出発点として使い、その後スキーマを論文の成果物として洗練してください。
• 推測せずにエビデンスパックから列を埋められない場合、そのスキーマは間違っています。