mcpField
A
appendix-table-writer

appendix-table-writer

github.com/willoscarドキュメント51738 回インストール4 週間前に更新
リポジトリ

appendix-table-writer について

appendix-table-writerは、既存のエビデンス資料から読者向けのサーベイ表を作るスキルです。手法、評価設定、リスクを簡潔な表に整理し、出力を検証します。

主な機能

  1. 01付録向けサーベイ表の作成
  2. 02エビデンス資料を表の根拠に利用
  3. 03手法、ベンチマーク、リスクの整理
  4. 04引用と表構造の検証
  5. 05検証レポートの作成

活用シーン

  1. 01サーベイ付録の表の準備
  2. 02エビデンスパックから比較可能な行を作成
  3. 03付録表の引用確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/willoscar/research-units-pipeline-skills --skill appendix-table-writer

インストール後、Claude Code で/appendix-table-writerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
table_cell_hygiene.json
references/
table_cell_hygiene.md
scripts/
run.py

詳細

付録表の作成(公開可能なサーベイ表)

トリガーと振り分け

  • トリガー:付録表、公開可能な表、サーベイ表、読者向けの表、附录表格、可发表表格、综述表格。
  • 使用する場面:C4 の成果物(エビデンスパック+アンカーシート+引用文献)があり、内部ログではなく、実際のサーベイにふさわしい表を作成したい場合。

このスキルが必要な理由

このパイプラインでは、計画やデバッグには役立つものの、内部資料のように見えるインデックス表を作成できます。

このスキルでは、付録に掲載できる、読者向けの公開可能な表を作成します。

  • すっきりしたレイアウト
  • 高い情報密度
  • 中間状態ではなく、サーベイ形式の構成(手法/ベンチマーク/リスク)

インデックス表は outline/tables_index.md に残し、論文にそのまま転載しないでください。

入力

  • outline/table_schema.md(表の目的+エビデンスの対応関係)
  • outline/tables_index.md(内部インデックス。任意ですが、推奨します)
  • outline/subsection_briefs.jsonl
  • outline/evidence_drafts.jsonl
  • outline/anchor_sheet.jsonl
  • citations/ref.bib
  • 任意:GOAL.md

必要に応じて読み込んでください。

  • 付録表のセルに論文の自己叙述や一般的な結果の枠組みがそのまま残っている場合は、references/table_cell_hygiene.md

機械可読アセット:

  • assets/table_cell_hygiene.json

出力

  • outline/tables_appendix.md

役割(明示的に使用)

サーベイ表キュレーター(読者の視点)

ミッション:読者がサーベイの付録で実際に必要とする表を選びます。

実施事項:

  • 大きな問い(手法、評価、リスク)に答える表を2~3個優先します
  • 表全体で行の単位をそろえ、比較可能にします
  • 論文全体を読まなくても理解できる表にします

避けること:

  • H3 ごとに1行を並べたインデックスの羅列
  • 内部向けの軸名(「axes」「blocking_missing」「evidence readiness」など)を列名にすること
制作エディター(レイアウト)

ミッション:LaTeX で公開できる見栄えの表にします。

実施事項:

  • 列数は4以下にします
  • セルは短くまとめます(文ではなく句にします)
  • <br> は控えめに使用します(1セルあたり0~1回。リストの羅列には使用しません)

避けること:

  • 小さくて読みにくい文字を含む6~8列の表
  • メモのようなセル(セミコロンでつないだ語句+スラッシュ区切りのリスト+長い括弧書き)
  • キャプション/見出し/セル内で軸をスラッシュ区切り(A/B/C)にすること(統合後の表現チェックで警告されます)。代わりにコンマまたは「and」を使います
  • 印刷すると中間資料のように見える内部向けの軸用語(例:表の列を「tokens」と呼ぶこと)。「protocol details/metadata/assumptions」などを優先します
エビデンス管理者(検証可能性)

ミッション:ハルシネーションを防ぎます。

実施事項:

  • 各行に専用列(例:「Key refs」)を設けて引用文献を記載します
  • エビデンスパック/アンカーシートにある内容だけを言い換えます
  • エビデンスが乏しい場合は、根拠の強い行を少数に絞ります

避けること:

  • パック/アンカーに裏付けとなる主張がない「代表的な研究」
  • 上流の資料にないベンチマーク/手法の詳細を追加すること

表の要件(公開可能、付録掲載に適した形式)

outline/tables_appendix.md は、以下の要件を満たす必要があります。

  • course_paper の場合は Markdown 表を1つ以上、survey/deep の場合は2つ以上含めます
  • 各表の前にキャプション行を置きます。例:**Appendix Table A1. Representative systems by method family and evaluation setting**
  • ファイル内に見出し(#、##、###)を含めません(統合時に付録の見出しが追加されます)
  • プレースホルダー(TODO、TBD、FIXME、ASCII の3点リーダー、Unicode の省略記号)を含めません
  • 各行に [@BibKey] 形式の引用文献を含めます(キーは citations/ref.bib に存在する必要があります)
  • パイプライン用語やインデックスのような列名を避けます

ワークフロー(明示的な入力)

  • GOAL.md(スコープ)と outline/table_schema.md(各表で答えるべき内容)を起点にします。
  • queries.md:draft_profile がある場合は読み込みます。デフォルトでは、course_paper には読者向けの質の高い表を1つ使用し、survey/deep には少なくとも2つ使用します。
  • outline/tables_index.md は候補の絞り込みに使いますが、そのまま貼り付けないでください。
  • outline/subsection_briefs.jsonl、outline/evidence_drafts.jsonl、outline/anchor_sheet.jsonl を使って行/セルを埋めます(推測は禁止)。
  • 引用するキーがすべて citations/ref.bib にあることを検証します。

推奨される付録の表(標準セット)

何を作成すればよいかわからない場合は、まず次の2つから始めてください。

  1. 手法/アーキテクチャの対応表(代表的な研究)
  • 行の単位:研究/システムの系統(H3 の ID ではありません)
  • 列(例):
    • 研究(短縮名)
    • 中核となるアイデア(短いフレーズ1つ)
    • ループとインターフェースの前提条件(読者向けの短いフレーズ1つ)
    • 主要な参照文献(引用キー2~4個)
  1. 評価プロトコル/ベンチマークの対応表
  • 行の単位:ベンチマーク/評価設定(ベンチマークが少ない場合は、標準的なプロトコルの側面)
  • 列(例):
    • ベンチマーク/設定
    • タスクと指標(定義ではなくフレーズ)
    • 主なプロトコル上の制約(予算/コスト/レイテンシー/ステップ数/ツールへのアクセス/脅威モデル)
    • 主要な参照文献(引用キー2~4個)

任意の3つ目(簡潔にまとめられる場合のみ): 3) リスク/脅威の対象範囲の対応表

  • 行の単位:脅威/障害モードのカテゴリ
  • 列:対象範囲;重要である理由;緩和策のパターン;主要な参照文献

良い例/悪い例(スタイル)

悪い例(索引表/内部メモ):

  • 列:「軸」
  • セル:planning / memory / tools / eval / safety(スラッシュで並べただけ)
  • 5行以上の <br> を含むすべての H3 ID を行にする

良い例(サーベイ表):

  • 列名は読者向けの表現(「中核となるアイデア」、「タスクと指標」、「制約」)
  • セルは短いフレーズ(説明文は含めない)
  • 読者が行をすばやく見比べられる

これも良い例(中間成果物らしさを避ける):

  • 列名に「token(s)」を使わない。必要な場合は、「プロトコルの詳細/メタデータ/前提条件」と表現し直してください。
  • セル内で -> のような ASCII 矢印を避け、自然な表現を使ってください(例:「推論のトレースとツール操作を交互に行う」)。

ここで終了する/上流に差し戻す場合

推測なしでは行を埋められない場合:

  • その行を削除し(確実な行を少数残すことを優先し)、
  • 上流に差し戻します。その領域の evidence-draft/anchor-sheet を強化してください。

スクリプト(生成と検証)

クイックスタート
  • uv run python .codex/skills/appendix-table-writer/scripts/run.py --help
  • uv run python .codex/skills/appendix-table-writer/scripts/run.py --workspace <workspace>
すべてのオプション
  • --workspace <workspace>(必須)
  • --unit-id <id>(任意。ランナーの管理にのみ使用)
  • --inputs <a;b;c>(任意。バリデーターでは無視され、ランナーとの互換性のために維持)
  • --outputs <relpath>(任意。デフォルトは outline/tables_appendix.md)
  • --checkpoint <C#>(任意。バリデーターでは無視)
例
  • デフォルトの付録の表ファイルを検証する:

    uv run python .codex/skills/appendix-table-writer/scripts/run.py --workspace workspaces/e2e-agent-survey-latex-verify-YYYYMMDD-HHMMSS

  • 標準以外のパスに付録の表を書き込むワークスペースを検証する:

    uv run python .codex/skills/appendix-table-writer/scripts/run.py --workspace <workspace> --outputs outline/tables_appendix.md

注:

  • このスクリプトは、既存のエビデンス成果物から outline/tables_appendix.md を書き込み、その後、結果を検証します。
  • 常に output/TABLES_APPENDIX_REPORT.md に短いレポートを書き込みます。

コメント