wiki-enrich

Wiki Enrich：論文の TODO セクションを埋める（Karpathy LLM-Wiki）

対象：$ARGUMENTS

このスキルが必要な理由

ingest_paper（/research-lit、/arxiv、/alphaxiv、/deepxiv、/semantic-scholar、/exa-search、/firecrawl-search から呼び出される）が生成するのは、論文ごとのひな形、つまりフロントマター＋要旨＋入力可能な _TODO._ プレースホルダーセクション 10 個だけです（保護対象のセクションが 2 つあり、## Connections はグラフの要約、## Abstract (original) は --arxiv-id が指定された場合に自動入力されます）。ARIS には、この 10 個のセクションを埋める後続スキルがありません。そのため、誰かが論文を 1 件ずつ読むまで、Wiki は TODO のままです。

これは Karpathy の LLM-Wiki 設計（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）に反しています。

「Wiki を自分で書くことはありません（あってもまれです）。LLM がすべてを書き、保守します。…ナレッジベースを保守するうえで面倒なのは、読んだり考えたりすることではなく、記録を管理することです。…LLM は飽きず、相互参照の更新を忘れず、1 回の処理で 15 個のファイルを編集できます。」

/wiki-enrich は ingest_paper の不足していた後半部分です。ひな形が作成された各論文ページを読み込み、フォールバックチェーン（5 つのソースからなる全体像は Phase 2.3 を参照）を使って外部ソースから論文の内容を取得し、入力可能な TODO セクション 10 個を、それぞれ 1〜3 文の要約文に書き換えます。

定数

• WIKI_ROOT = research-wiki/ — git ルートからの相対パスとして解決されます。ディレクトリでない場合、スキルはハードエラーで終了します。
• TARGET_DEFAULT = missing — ターゲットが指定されていない場合、TODO セクションが 1 つ以上ある論文のみを充実させます。その他のターゲット：<slug>（1 件の論文）または all（すでに充実している論文も含むすべての論文。上書きする場合は通常 --force と併用します）。
• SOURCE_DEFAULT = auto — 取得順：alphaxiv overview → alphaxiv abs → deepxiv brief → arXiv API の概要 → ページの概要へのフォールバック。最初に見つかった空でない項目を使用します（全取得順は Phase 2.3 の表に記載）。1 つのソースに固定するには --source で上書きします。
• MAX_PAPERS = 20 — 1 回の実行あたりの上限です。LLM は多くのファイルを処理しますが、トークン予算には限りがあります。--max N で上書きできます。
• FORCE = false — false（デフォルト）の場合、すでに TODO 以外の内容があるセクションはスキップします。true の場合、入力可能なセクションをすべて上書きします。ただし、保護対象の 2 つのセクション、## Connections（edges.jsonl から自動生成）と ## Abstract (original)（変更不可の arXiv 取得元データ）は決して変更しません。
• SECTIONS_TO_FILL — 入力可能なセクションが 10 個、保護対象が 2 個あります。ingest_paper（research_wiki.py:436-473）は 11 個のセクション見出しを常に生成し、さらに、指定された --arxiv-id に対して arXiv が概要を返した場合に限り、12 個目の ## Abstract (original) を生成します（research_wiki.py:469-473）。このうち 10 個には _TODO._（または _TODO: fill in after reading._）マーカーが付いており、入力が必要です。残りの 2 個、列挙順で 10 番目の ## Connections と、条件付きの 12 番目の ## Abstract (original) は、仕様上保護されています。Connections は graph/edges.jsonl から自動生成され、Abstract (original) は arXiv API から取得した変更不可のソースデータです。このスキルが書き込むのは 10 個のセクションであり、保護対象の 2 個には書き込みません。
  1. One-line thesis（マーカー：_TODO: fill in after reading._）
  2. Problem / Gap（マーカー：_TODO._）
  3. Method（マーカー：_TODO._）
  4. Key Results（マーカー：_TODO._）
  5. Assumptions（マーカー：_TODO._）
  6. Limitations / Failure Modes（マーカー：_TODO._）
  7. Reusable Ingredients（マーカー：_TODO._）
  8. Open Questions（マーカー：_TODO._）
  9. Claims（マーカー：_TODO._）— この論文を指す claim: エッジがない場合は _No claims tracked yet._ を入力し、ある場合はそれらを列挙します。
  10. Connections — 編集禁止（graph/edges.jsonl から自動生成）。
  11. Relevance to This Project（マーカー：_TODO._）— プロジェクトの背景には RESEARCH_BRIEF.md、AGENTS.md（または旧式の CLAUDE.md）、あるいは gap_map.md を使用します。プロジェクトの背景情報がない場合は TODO のままにして、その旨を報告します。
  12. Abstract (original) — そのままにします（--arxiv-id が使用された場合、すでに ingest_paper によって入力されています）。

💡 例：

• /wiki-enrich — TODO セクションが 1 つ以上あるすべての論文を充実させます（最も一般的な使い方）。
• /wiki-enrich vllm — スラッグで指定した 1 件の論文を充実させます。
• /wiki-enrich all --force — すべての論文を最初から書き直します（新しいスタイルを採用した場合に使用）。
• /wiki-enrich --source alphaxiv --max 5 — alphaxiv のみを使用し、論文を 5 件だけ処理します。
• /wiki-enrich missing --max 50 — より大きなバッチで処理します（トークン予算に注意してください）。

実行前チェック

$WIKI_ROOT と $WIKI_SCRIPT を解決します（標準の解決手順 — shared-references/wiki-helper-resolution.md を参照）。

cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
[ -d research-wiki/ ] || { echo "ERROR: research-wiki/ not found. Run /research-wiki init first." >&2; exit 1; }

ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills-codex.txt 2>/dev/null)}"
WIKI_SCRIPT=""
[ -n "$ARIS_REPO" ] && [ -f "$ARIS_REPO/tools/research_wiki.py" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"
[ -z "$WIKI_SCRIPT" ] && [ -f tools/research_wiki.py ] && WIKI_SCRIPT="tools/research_wiki.py"
[ -z "$WIKI_SCRIPT" ] && [ -f ~/.codex/skills/research-wiki/research_wiki.py ] && WIKI_SCRIPT="$HOME/.codex/skills/research-wiki/research_wiki.py"
[ -n "$WIKI_SCRIPT" ] || { echo "ERROR: research_wiki.py not found." >&2; exit 1; }

どちらかの解決に失敗した場合は、ハードエラーで終了します。このスキルは Wiki の状態を操作するため、状況を把握せずに実行してはなりません。

ワークフロー

フェーズ 1：ターゲットの解析と候補の検出

$ARGUMENTS から、最初の位置引数（ターゲット）とフラグ（--source、--force、--max）を解析します。

候補となる論文のリストを作成します。

case "$TARGET" in
  all)
    PAPERS=( research-wiki/papers/*.md )
    ;;
  missing|"")
    # only papers with at least one TODO marker line
    PAPERS=( $(grep -lE "^_TODO(\._?|: fill in after reading\._?)$" research-wiki/papers/*.md 2>/dev/null) )
    ;;
  *)
    P="research-wiki/papers/${TARGET}.md"
    [ -f "$P" ] || { echo "ERROR: paper not found: $P" >&2; exit 1; }
    PAPERS=( "$P" )
    ;;
esac
echo "Candidate papers: ${#PAPERS[@]} (cap ${MAX_PAPERS})"
PAPERS=( "${PAPERS[@]:0:${MAX_PAPERS}}" )

候補リストが空の場合は、"✓ Nothing to enrich." と出力して、終了コード 0 で終了します。エラーにはしません。

フェーズ 2：論文ごとに読み込み、取得、入力

論文を 1 件ずつ処理します。$PAPERS 内の各 $PAPER に対して、以下を実行します。 Step 2.1 — ページとプロジェクトのコンテキストを読み取ります。 論文ファイル全体に対して Read ツールを使用します。YAML フロントマターから次の項目を抽出します。

• node_id（例：paper:vllm）— スラッグ = paper: の後ろの部分
• external_ids.arxiv の arxiv — 存在しない場合は空文字列
• title
• 既存の ## Abstract (original) 引用ブロック（存在する場合）— フォールバック用のコンテンツソース

さらに、バッチ内の最初の論文では（以降の論文でキャッシュして使用）、Claims セクションと Relevance to This Project セクションに必要なプロジェクトコンテキストファイルを読み取ります。

• research-wiki/graph/edges.jsonl — 現在の論文の node_id を参照する claim: エッジを検索します
• RESEARCH_BRIEF.md（プロジェクトルート）— 存在する場合は、プロジェクトの目標のソースとして使用します
• AGENTS.md（プロジェクトルート、Codex CLI を優先）または旧形式の CLAUDE.md — 存在する場合は、プロジェクトコンテキストのフォールバックとして使用します
• research-wiki/gap_map.md — 空でない場合は、ギャップの説明のソースとして使用します

プロジェクトコンテキストファイルが存在しない場合、Relevance to This Project セクションには文字列 "context not yet set" の行をそのまま記入します（Step 2.4 の表を参照）。

Step 2.2 — TODO のセクションを特定します。

各セクション見出しとそのマーカーを照合します。

• 見出しの直後が厳密に _TODO._ の場合 → 記入します
• 見出しの直後が _TODO: fill in after reading._ の場合 → 記入します（One-line thesis）
• 見出しの直後にそれ以外の内容がある場合 → スキップします（--force の場合を除く）
• ## Connections → 常にスキップします（自動生成）
• ## Abstract (original) → 常にスキップします（変更不可のソースデータ）

記入可能なセクションが残っていない場合は、"skip: <slug> (already enriched)" をログに記録して続行します。

Step 2.3 — ソースコンテンツを取得します。

取得チェーンは、使用可能なコンテンツ（テキストが 200 文字を超えるもの）が返されるまで、以下の順序で実行します。

順序	ソース	方法
1	alphaxiv overview（デフォルトは auto、固定する場合は --source alphaxiv）	WebFetch https://www.alphaxiv.org/overview/<arxiv_id>.md — LLM 向けに最適化された要約で、セクションの記入に最適なことが多いです
2	alphaxiv abs（alphaxiv 内のフォールバック）	WebFetch https://www.alphaxiv.org/abs/<arxiv_id>.md
3	deepxiv brief（固定する場合は --source deepxiv）	ヘルパーの場所を解決できる場合は python3 "$DEEPXIV_FETCHER" paper-brief <arxiv_id>
4	arXiv API abstract — 新規取得（固定する場合は --source arxiv）	curl http://export.arxiv.org/api/query?id_list=<arxiv_id> — ログラベル：arxiv-api-abstract
5	ページの abstract — フォールバック（最後の手段）	以前の ingest_paper 実行でページ本文にすでに存在している ## Abstract (original) 引用ブロックを再利用します — ログラベル：page-abstract-fallback
—	arxiv ID なし + ページの abstract なし	この論文をスキップし、"skip: <slug> (no arxiv id, no abstract)" をログに記録して続行します

alphaxiv を試す際、WebFetch が 404／「Paper not found」／ホームページへのリダイレクトを返した場合は、取得失敗とみなし、次の手順に進みます。

deepxiv を試す際は、shared-references/integration-contract.md に従って $DEEPXIV_FETCHER の場所を解決します。ヘルパーまたは deepxiv CLI が見つからない場合は、何も記録せずに次の手順に進みます。

取得したコンテンツを $SOURCE_TEXT として保存します。ログエントリーに、成功したソースを記録します。

Step 2.4 — セクションごとのコンテンツを生成します。

あなた（実行エージェント）が、実作業を行う LLM です。以下を与えられたら：

• $SOURCE_TEXT（取得した overview／brief／abstract）
• $TITLE
• 記入可能なセクション見出しのリスト

次のルールに従い、各 TODO セクションの本文を記述します。

セクション	長さ	スタイル	抽出する内容
1文の主張	1文、≤25語	断定的	論文の中心的な貢献を1文で — 構築／証明／改善したもの
問題／ギャップ	1〜2文	断定的	この分野が抱えていた問題と、先行研究では不十分だった理由
手法	2〜4文	技術的、手法名を明記	中核となる仕組み — アルゴリズム名＋主要なアイデア＋ベースラインとの違い
主な結果	1〜3個の箇条書き、または2〜3文	定量的	アブストラクト／概要にある主要な数値（X%の改善、Y倍の高速化など）。単位は原文のままにします。
前提	1〜3個の箇条書き	断定的	論文が前提としているもの（ワークロードの種類、ハードウェア、モデルのクラス、分布の形状）
限界／失敗モード	1〜3個の箇条書き	率直	論文が明示的に認めていること、または構造的に欠けていること（例：「マルチノード評価がない」、「リクエスト長が一様であると仮定する」）
再利用可能な要素	1〜3個の箇条書き	具体的	他の場所に移植できる、この論文の手法／データセット／知見。/idea-creator にとって最も価値の高い項目です — 丁寧に記述してください。
未解決の問い	1〜2個の箇条書き	疑問形	論文では答えていないが、提起される問い
主張	1行	固定形式	graph/edges.jsonl にある claim: エッジのうち、この論文を参照するものがない場合は、次のイタリック体の文をそのまま記述します：_No claims tracked yet — populate via /proof-checker._。ある場合は、claim ノード ID を列挙します。
このプロジェクトとの関連性	1〜2文	プロジェクトの文脈に沿った内容	RESEARCH_BRIEF.md／AGENTS.md（または旧版の CLAUDE.md）／gap_map.md を使って関連性を記述します。プロジェクトの文脈がない場合は、次のイタリック体の文をそのまま記述し、報告します：_Project context not yet set — populate RESEARCH_BRIEF.md or gap_map.md to enable this section._

ルール（Karpathy の忠実性）：

• 原文に忠実にします。 論文に書かれていないことは作り出しません。幻覚を避けるため、_Not stated in source._ を優先します。
• 水増ししません。 「この論文では、ある手法を提案します……」とは書きません。名詞から書き始めます。
• 技術用語は英語のままにします。 vLLM、KV cache、prefill、decode、TTFT などは原文のままにします。
• 可能な限り定量的にします。 アブストラクトに数値がある場合は使用し、「大幅な改善」のように言い換えません。
• バイリンガル対応。 プロジェクトの AGENTS.md で言語の希望（language: zh または language: bilingual）が宣言されている場合は、それに従います。それ以外の場合は英語を既定とします（または shared-references/output-language.md に従います）。

Step 2.5 — ファイルを編集します。

入力可能な各セクションについて、Edit ツールを使って TODO マーカーを生成した本文に置き換えます。編集箇所を一意に保つため、正確なセクション見出し＋マーカーの組み合わせに一致させます。例：

## Problem / Gap
_TODO._

→

## Problem / Gap
<generated body>

絶対に YAML フロントマター、## Connections、または ## Abstract (original) を変更しないでください。

Step 2.6 — ログエントリを追加します。

python3 "$WIKI_SCRIPT" log research-wiki/ "wiki-enrich: enriched paper:<slug> from <source> (filled N/M sections)"

内容の提供元（alphaxiv-overview、alphaxiv-abs、deepxiv-brief、arxiv-api-abstract、または page-abstract-fallback）を記録し、監査証跡で出典を正確に示します。

Phase 3: 最終レポート

すべての候補を処理した後、次を出力します：

✓ wiki-enrich complete

Processed:  N
Enriched:   X (sections filled: total)
Skipped:    Y  (reasons: already enriched / no arxiv id / fetch failed)
Failed:     Z  (with paper + reason)

Source breakdown:
  alphaxiv-overview: A
  alphaxiv-abs:      B
  deepxiv-brief:     C
  arxiv-api-abstract:     D
  page-abstract-fallback: E

Re-ideation suggestion: <if ≥5 papers were enriched, recommend `/idea-creator "topic"` so the freshly-filled `Reusable Ingredients` and `Limitations` feed brainstorming. `query_pack.md` is already rebuilt below — the user does NOT need to call `/research-wiki query` manually.>

最後に一度だけ query_pack.md も再構築します（python3 "$WIKI_SCRIPT" rebuild_query_pack research-wiki/ を呼び出します）。これにより、次回の /idea-creator 実行時に新しい本文が反映されます。

出力プロトコル

共通プロトコルに従います：

• MANIFEST.md エントリは追加しません。 このスキルは新しい成果物を生成するのではなく、既存のひな形ページをその場で編集します。監査証跡は、論文ごとの出典情報とともに research-wiki/log.md（Step 2.6）に記録されます。この PR で shared-references/output-manifest.md に wiki-enrich ステージを追加することは対象外です。
• 出力言語プロトコル — プロジェクトの言語設定に従います。

主なルール

• デフォルトでは冪等です。 --force を指定せずに再実行すると、TODO のままのセクションのみが処理されます。cron から安全に実行できます。
• フロントマター、## Connections、## Abstract (original) には触れません。 フロントマターはメタデータ、Connections はグラフによって生成されるもの、Abstract は変更不可のソースデータです。
• wiki またはヘルパーが見つからない場合は、必ずエラーで終了します。 research-wiki/ を黙って作成してはいけません。見つからない場合は、ユーザーが間違った cwd にいるか、/research-wiki init を実行していません。
• 出典を記録します。 各ログエントリーには、本文の作成に実際に使われたソースを記録します。後日監査で、ある論文について alphaxiv が誤情報を生成したと判明した場合、そのソースが使われたすべてのページを特定できます。
• /idea-creator を自動的に起動しません。 このスキルは基盤を構築するものであり、次にブレインストーミングを行うかどうかはユーザーが決めます。最終レポートでは、再度アイデアを考えることを提案するだけにしてください。
• 状況に応じて柔軟に対処します。 WebFetch がレート制限された場合は、次のソースに進みます。すべてのソースで見つからない場合は、その論文をスキップして続行し、バッチ全体を中断しないでください。
• 完全性よりも Karpathy への忠実性を優先します。 幻覚を生成するくらいなら、セクションを _Not stated in source._ のままにするほうが適切です。wiki の価値は、嘘をつかないことにあります。

他のスキルとの組み合わせ

/research-lit "topic"               ← ingests papers as scaffolds (Step 6)
/wiki-enrich                        ← THIS — fills paper bodies (you are here)
/research-wiki lint                 ← health-check (orphans, contradictions, dead ideas)
/idea-creator "direction"           ← reads query_pack, ideates on top of enriched wiki
/research-wiki query "topic"        ← rebuild query_pack after big wiki changes

新たに /research-pipeline を実行した後、Stage 1 Phase 1 は完了したものの Phase 2 が開始されていない場合（このスキルのきっかけとなった失敗パターン）の復旧手順は次のとおりです。

/wiki-enrich              # fill the paper TODOs ingest_paper left behind
/idea-creator "..."        # now ideate with a wiki that actually has content