research-wiki

リサーチウィキ：永続的なリサーチナレッジベース

サブコマンド：$ARGUMENTS

概要

リサーチウィキは、プロジェクトごとに永続化され、ARIS のリサーチライフサイクル全体を通じて構造化された知識を蓄積するナレッジベースです。使い捨ての文献調査のように、利用した後に忘れられることはありません。ウィキは蓄積によって価値を高めます。読んだ論文、検証したアイデア、実施した実験、受けたレビューのすべてが、ウィキをより賢くします。

Karpathy の LLM Wiki パターンに着想を得ています。一度知識をまとめ、最新の状態に保ち、クエリのたびに一から導き出すことはしません。

基本概念

4 種類のエンティティ

エンティティ	ディレクトリ	ノード ID の形式	表すもの
論文	papers/	paper:<slug>	出版済みまたはプレプリントの研究論文
アイデア	ideas/	idea:<id>	研究アイデア（提案、検証済み、または失敗）
実験	experiments/	exp:<id>	結果を伴う具体的な実験の実施
主張	claims/	claim:<id>	正直な PROOF ステータスを伴う定理／主張。/proof-checker 経由で作成されます（Hook 4 を参照）

型付きリレーションシップ（graph/edges.jsonl）

エッジタイプ	From → To	意味
extends	論文 → 論文	先行研究を発展させます
contradicts	論文 → 論文	結果／主張に異議を唱えます
addresses_gap	論文|アイデア → ギャップ	既知の研究分野のギャップを対象とします
inspired_by	アイデア → 論文	この論文に着想を得たアイデアです
tested_by	アイデア|主張 → 実験	この実験で検証されました
supports	実験 → 主張|アイデア	実験が主張を裏付けます
invalidates	実験 → 主張|アイデア	実験が主張を否定します
supersedes	論文 → 論文	新しい研究が古い研究に取って代わります

エッジは graph/edges.jsonl のみに保存されます。各ページの ## Connections セクションはグラフから自動生成されるため、手動で編集しないでください。

記録時の衛生管理（自己汚染の防止）

アイデア／主張／実験のメモを保存する前に、自己引用される誤情報として定着するおそれのある運用上のノイズがないか確認してください（shared-references/capture-antipatterns.md を参照）。 ヘルパーは正規のチェーン（integration-contract §2）を使って解決してください。 .aris/tools/capture_filter.py → tools/capture_filter.py → $ARIS_REPO/tools/capture_filter.py（解決できない場合は警告してスキップ）。メモのテキストに対して python3 <capture_filter> - を実行します。env-failure / transient-error / negative-tool-claim が検出された場合、永続ノードとして保存してはなりません。 修正方法／不足している設定／回避策に書き換えるか、破棄してください。「codex/gemini/レビュアーには X ができない」といった内容は決して保存しないでください。これは将来のすべてのセッションで読み込まれ、本当の原因がなくなった後もエージェントに対して引用されることになります。（ウィキの「失敗したアイデア → 再発防止の記憶」はその正しい逆の例であり、運用上のノイズではなく、クラスレベルの研究上の知見です。）

ウィキのディレクトリ構造

research-wiki/
  index.md               # categorical index (auto-generated)
  log.md                 # append-only timeline
  gap_map.md             # field gaps with stable IDs (G1, G2, ...)
  query_pack.md          # compressed summary for /idea-creator (auto-generated, max 8000 chars)
  papers/
    <slug>.md            # one page per paper
  ideas/
    <idea_id>.md         # one page per idea
  experiments/
    <exp_id>.md          # one page per experiment
  claims/
    <claim_id>.md        # one page per testable claim
  graph/
    edges.jsonl          # materialized current relationship graph

サブコマンド

ヘルパーの解決（以下のサブコマンドを実行する前に実施）

単なるディレクトリの初期化を除くすべてのウィキ操作では、単一の正規ヘルパー tools/research_wiki.py を使用します。ウィキを操作するスキルでは、以下のチェーンを使って $WIKI_SCRIPT を解決してください。python3 tools/research_wiki.py … のように直接指定してはなりません。プロジェクトに tools/ が存在しない場合（install_aris.sh 実行後の既定の状態）、直接指定するとエラーが通知されないまま失敗します。これは、実際にユーザーの research-wiki/ が 1 週間空のままだった原因そのものです。

cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null)}"
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
  ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
WIKI_SCRIPT=".aris/tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || WIKI_SCRIPT="tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || { [ -n "${ARIS_REPO:-}" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"; }
[ -f "$WIKI_SCRIPT" ] || {
  echo "ERROR: research_wiki.py not found at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix one of:" >&2
  echo "         1. rerun 'bash tools/install_aris.sh' from the ARIS repo (creates .aris/tools symlink, refreshes ~/.aris/repo)" >&2
  echo "         2. rerun 'bash tools/smart_update.sh' (refreshes ~/.aris/repo)" >&2
  echo "         3. export ARIS_REPO=<path-to-ARIS-repo>" >&2
  echo "         4. cp <ARIS-repo>/tools/research_wiki.py tools/" >&2
  exit 1
}

/research-wiki 自体がウィキツールです。ヘルパーが見つからない場合、スキルは処理を中断して失敗します。副作用としてウィキを更新する呼び出し元スキル（/idea-creator、/result-to-claim、/research-lit、/arxiv、/alphaxiv、/deepxiv、/semantic-scholar、/exa-search、/firecrawl-search）も同じチェーンを使いますが、処理を中断せず、警告してスキップします。主要な出力（アイデアの一覧、主張の判定、論文の要約）は、引き続きユーザーに提供する必要があります。

/research-wiki init

現在のプロジェクト用に Wiki を初期化します。上記のチェーンに従って $WIKI_SCRIPT を解決した後、次を実行します。

python3 "$WIKI_SCRIPT" init research-wiki/

ヘルパーは research-wiki/{papers,ideas,experiments,claims,graph}/ と、index.md、log.md、gap_map.md、query_pack.md、 graph/edges.jsonl を作成し、その後 log.md に "Wiki initialized" を追記します。

（このスキルの以前のバージョンでは、query_pack.md を省略する文章のみの init が説明されていましたが、これはヘルパーの動作と異なっており、/idea-creator の Phase 0 でのクエリパック確認が rebuild_query_pack の呼び出しに進み、旧来のハードコードされたパスではそれがひそかに失敗していました。init をヘルパーに委任することで、Wiki スキーマの唯一の信頼できる情報源になります。）

/research-wiki ingest "<paper title>" — arxiv: <id>

論文を Wiki に追加します。このサブコマンドは、 python3 "$WIKI_SCRIPT" ingest_paper … を呼び出す薄いラッパーです。これは ARIS における論文取り込みの唯一の実装です（ shared-references/integration-contract.md を参照 — ヘルパーは 1 つで、コピーはありません）。ヘルパーは次のすべてを実行します。

1. メタデータを取得 — --arxiv-id が指定されている場合は arXiv Atom API に問い合わせます
2. スラッグを生成 — <first_author_last_name><year>_<keyword>
3. 重複を確認 — --update-on-exist が指定されていない限り、既存のページはスキップします
4. ページを作成 — 以下のスキーマで papers/<slug>.md を作成します
5. index.md と query_pack.md を再構築
6. log.md に追記

エッジの抽出（旧来の手動フローにおけるステップ 5/8）は ingest_paper に含まれていません。識別した関係ごとに add_edge を使って、後続の処理として実行してください。

# arXiv-known paper
python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ \
    --arxiv-id 2501.12345 --thesis "One-line claim from abstract."

# Venue paper with no arXiv mirror
python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ \
    --title "Attention Is All You Need" \
    --authors "Ashish Vaswani, Noam Shazeer, …" --year 2017 --venue "NeurIPS"

# Manual edge after ingest
python3 "$WIKI_SCRIPT" add_edge research-wiki/ \
    --from "paper:vaswani2017_attention_all_you" \
    --to "paper:chen2025_factorized_gap" \
    --type "extends" --evidence "Section 3.2: adapts the encoder block …"

他のスキル（/research-lit、/arxiv、/alphaxiv、/deepxiv、 /semantic-scholar、/exa-search、/firecrawl-search）も、最後のステップで同じヘルパーを直接呼び出します。サブコマンドとして /research-wiki ingest を経由することはないため、LLM のラウンドトリップは必要ありません。

/research-wiki sync — arxiv-ids <id1>,<id2>,...

一括バックフィル：以前に読み、取り込みが行われていなかった 1 つ以上の arXiv ID を取り込みます（例：読み終えた後に research-wiki/ が設定された場合や、フックが起動しなかった場合）。

# Explicit list
python3 "$WIKI_SCRIPT" sync research-wiki/ \
    --arxiv-ids 2310.06770,1706.03762

# From a file (one id per line, # comments ok)
python3 "$WIKI_SCRIPT" sync research-wiki/ --from-file ids.txt

重複は ID ごとに処理され、すでに取り込み済みの論文は何も通知せずにスキップされます。これは推奨される手動修復の手順です（integration contract §5 Backfill を参照）。sync はセッショントレースをスキャンしません — 呼び出し元が ID を明示的に指定します。

論文ページのスキーマ（ingest_paper が出力するものと完全に同一です — 別のフィールドを手書きしないでください。lint が差異を検出します）：

---
type: paper
node_id: paper:<slug>
title: "<full title>"
authors: ["First A. Author", "Second B. Author"]
year: 2025
venue: "arXiv"
external_ids:
  arxiv: "2501.12345"
  doi: null
  s2: null
tags: ["tag1", "tag2"]
added: 2026-04-07T10:12:00Z
---

# <full title>

## One-line thesis

[Single sentence capturing the paper's core contribution]

## Problem / Gap

## Method

## Key Results

## Assumptions

## Limitations / Failure Modes

## Reusable Ingredients

[Techniques, datasets, or insights that could be repurposed]

## Open Questions

## Claims

[Reference claim pages: claim:C1, claim:C2, etc.]

## Connections

[AUTO-GENERATED from graph/edges.jsonl — do not edit manually]

## Relevance to This Project

[Why this paper matters for our specific research direction]

さらに、論文が --arxiv-id を指定して取り込まれ、arXiv API からアブストラクトが返された場合、ヘルパーは Relevance to This Project の後に ## Abstract (original) セクションを追加し、未加工のアブストラクトテキストを引用ブロックとして含めます。手動で取り込んだ場合（--arxiv-id なし）、このセクションは含まれません。

/research-wiki query "<topic>"

query_pack.md を生成します — コンテキストウィンドウに収まりやすい、圧縮された要約です：

固定の予算（最大 8000 文字／約 2000 トークン）：

セクション	予算	内容
プロジェクトの方向性	セクション全体	RESEARCH_BRIEF.md から、## 見出し（Problem / Constraints / Direction / Background / Non-Goals / Domain Knowledge / Existing Results）ごとに優先順で構造化して抽出します。フィールドごとの文字数上限はありません。8000 文字の組み立てループのみを安全策とします。既知の見出しが使われていない場合は、先頭から 600 文字をそのまま使用します。
上位 5 件のギャップ	1200 文字	gap_map.md から、未解決 + 関連アイデア + 失敗した実験の順にランク付けします
論文クラスター	1600 文字	タグの重なりに基づく 3〜5 個のクラスター。各クラスターを 2〜3 文で説明します
失敗したアイデア	1400 文字	必ず含めます — 繰り返しを防ぐ価値が最も高いためです
上位の論文	1800 文字	関連するギャップ、関連するアイデア、中心性、関連性フラグの順にランク付けした 8〜12 ページ
進行中の連鎖	900 文字	限界 → 機会の関係性を示す連鎖
未解決の疑問	500 文字	Wiki 全体にわたる未解決の質問

削減の優先順位（予算を超過した場合）：順位の低い論文 > クラスターの詳細 > 連鎖の詳細。失敗したアイデアや上位のギャップを先に削減してはいけません。

重要なルール： 短いフィールド（フロントマター、1 行の論旨、ギャップの要約、失敗のメモ）のみを読み取ってください。毎回、ページ本文全体を要約しないでください。

/research-wiki update <node_id> — <field>: <value>

特定のエンティティを更新します：

/research-wiki update paper:chen2025 — relevance: core
/research-wiki update idea:001 — outcome: negative
/research-wiki update claim:C1 — status: refuted

更新後は必ず、query_pack.md を再構築し、log.md を更新します。

/research-wiki lint

Wiki の健全性をチェックします：

1. 孤立ページ — エッジが 0 個のエンティティ
2. 古い主張 — status: drafted または status: unproven のまま 14 日以上経過している主張
3. 矛盾 — supports と invalidates の両方のエッジがある主張
4. 接続の不足 — 2 個以上のタグを共有しているが、明示的な関係がない論文
5. 進展のないアイデア — 一度もテストされていない stage: proposed のアイデア
6. 情報の少ないページ — 3 つ以上のセクションが空のページ

修正案を記載した LINT_REPORT.md を出力します。

/research-wiki stats

簡単な概要：

📚 Research Wiki Stats
Papers: 28 (12 core, 10 related, 6 peripheral)
Ideas: 7 (2 active, 3 failed, 1 partial, 1 succeeded)
Experiments: 12
Claims: 15 (8 verified, 4 unproven, 2 refuted, 1 sound-modulo-imports)
Edges: 64
Gaps: 8 (3 unresolved)
Last updated: 2026-04-07T10:12:00Z

既存のワークフローとの統合

すべての論文読解スキルは、同じ統合契約に従います（shared-references/integration-contract.md を参照）：

• 単一の判定条件 — [ -d research-wiki/ ]
• 単一の標準ヘルパー — この SKILL の先頭にあるチェーンをたどって $WIKI_SCRIPT を解決した後、python3 "$WIKI_SCRIPT" ingest_paper … を実行
• 具体的な成果物 — papers/<slug>.md + log.md のエントリー
• バックフィル — sync --arxiv-ids …
• 診断 — verify_wiki_coverage.sh（Policy E；integration-contract §2 に従って解決）

フック 1：/research-lit が論文を見つけた後

# At end of research-lit, after synthesis:
if research-wiki/ exists AND $WIKI_SCRIPT resolved (chain at top of this SKILL):
    for paper in top_relevant_papers (limit 8-12):
        python3 "$WIKI_SCRIPT" ingest_paper research-wiki/ \
            --arxiv-id <id> [--thesis "..."] [--tags "..."]
        for each explicit relation to existing wiki paper:
            python3 "$WIKI_SCRIPT" add_edge research-wiki/ \
                --from "paper:<slug>" --to "<target>" \
                --type <extends|contradicts|addresses_gap|...> \
                --evidence "..."
    log "research-lit ingested N papers"
elif research-wiki/ exists but $WIKI_SCRIPT did not resolve:
    warn "wiki update skipped — research_wiki.py unreachable; rerun install_aris.sh"

各論文読解スキルには、アクティブな場合に同じヘルパーを対象の論文ごとに 1 回呼び出す「Update Research Wiki」ステップが含まれています。ビジネスロジックは重複させず、各スキル固有の結果セットを走査するループだけが異なります。

フック 2：/idea-creator による Wiki の読み書き

アイデア生成の前：

if research-wiki/query_pack.md exists (and < 7 days old):
    prepend query_pack to landscape context
    treat failed ideas as banlist
    treat top gaps as search seeds
    still run fresh literature search for last 3-6 months

アイデア生成の後（重要 — これがないと ideas/ は空のままです。制約を更新して再実行する場合も含め、生成のたびに実行します）： ページの書き込みは、モデルが省略できる自由記述のステップではなく、決定論的なヘルパーコマンドです：

for idea in all_generated_ideas (recommended + killed):
    python3 "$WIKI_SCRIPT" upsert_idea research-wiki/ \
      --slug <stable-id> --title <title> --stage <proposed|archived> --outcome pending \
      --thesis <...> --risks <...> --based-on <paper:slug,...> --target-gaps <G2,...>
    # one call: writes ideas/<slug>.md, wires inspired_by/addresses_gap edges,
    # rebuilds index + query_pack, logs. Default skip-on-exist (won't clobber an
    # existing idea enriched by /result-to-claim). `outcome` ∈ {unknown, pending,
    # negative, mixed, positive} — the experiment verdict is set later by
    # /result-to-claim, never guessed at ideation.
log "idea-creator wrote N ideas to wiki"

フック 3：/result-to-claim の判定後

# Create/refresh the experiment node FIRST via the deterministic helper (verdict owner
# → --update-on-exist). This is the experiment BIRTH point. add_edge does NOT verify
# node existence, so GATE the supports/invalidates edges below on the node having been
# born (EXP_NODE_OK) — else they'd dangle off a missing exp node.
EXP_NODE_OK = (python3 "$WIKI_SCRIPT" add_experiment research-wiki/ --slug <exp_id> \
  --idea idea:<active_idea> --verdict <yes|partial|no> --confidence <high|medium|low> \
  --metrics <...> --reasoning <...> --provenance <run dir> --update-on-exist) succeeded
  # writes page + idea--tested_by-->exp edge + rebuilds index/query_pack

# Record empirical support as EDGES ONLY, and ONLY if EXP_NODE_OK — never overwrite the
# claim's `status`. A claim's `status` is the PROOF axis (verified / sound-modulo-imports
# / refuted / unproven / drafted / retracted), owned by /proof-checker (the claim birth
# point). Experiment support is a SEPARATE axis carried entirely by supports/invalidates
# edges; writing "supported"/"invalidated" into status is rejected by the validator.
if EXP_NODE_OK:
    for claim_id in resolved_claims:
        if verdict == "yes":
            add_edge(exp_id, claim_id, "supports")
        elif verdict == "partial":
            add_edge(exp_id, claim_id, "supports")   # partial — qualify in --evidence
        else:
            add_edge(exp_id, claim_id, "invalidates")

# Update idea outcome
update_idea(active_idea_id, outcome=verdict)

# If failed, record WHY for future ideation
if verdict in ("no", "partial"):
    update_idea failure_notes with specific metrics and reasons

rebuild query_pack
log "result-to-claim: exp_id updated, verdict=..."

Hook 4: 主張の作成 — /proof-checker から（唯一の作成ポイント）

Wiki の主張ノードはここで作成されます。 /proof-checker の Phase 5.5 では、PROOF_AUDIT.json の書き込み後、トップレベルの定理／見出しごとに add_claim を呼び出し、正直な PROOF 軸の status と、監査トレースを指す provenance を記録します。主張ノードを作成するスキルはほかにありません。Hook 3 の /result-to-claim は、すでに作成された主張に経験的な supports／invalidates エッジを追加するだけで、status は決して編集しません。

# (run by /proof-checker; shown here for the wiki's record)
python3 "$WIKI_SCRIPT" add_claim research-wiki/ --slug thm-main-ub \
  --name "Main upper bound" --status verified \
  --provenance ".aris/traces/proof-checker/<run>/" --statement "..." --update-on-exist

主張の status ∈ {drafted, unproven, sound-modulo-imports, verified, refuted, retracted} — 証明軸のみを表します。経験的な支持は別の軸であり、すべてエッジ（Hook 3）で表現され、status に書き込まれることはありません。

再アイデア化のトリガー

Wiki を大幅に更新した後は、/idea-creator の再実行を提案します。

• 前回のアイデア化以降に取り込んだ新しい論文が5件以上
• 前回のアイデア化以降に失敗または部分的に失敗した新しいアイデアが3件以上
• グラフ内で新たな矛盾が見つかった
• 既存のアイデアでは対応できない新たなギャップが特定された

システムは提案しますが、自動では実行しません。ユーザーが決定します。

主なルール

• 関係の信頼できる唯一の情報源：graph/edges.jsonl。ページの Connections セクションは自動生成されたビューです。
• すべての場所で正規ノード ID を使用：paper:<slug>、idea:<id>、exp:<id>、claim:<id>、gap:<id>。生のタイトルや一貫性のない略称は決して使用しないでください。
• 失敗したアイデアは最も価値のある記憶です。 query_pack から決して削除しないでください。
• query_pack.md は8000文字の上限が厳密に設定されています。 自由形式の要約ではなく、決定論的に生成してください。
• 変更のたびに log.md に追記してください。 ログは監査証跡です。
• レビュアーの独立性を保ってください。 Wiki がクロスモデルレビュー用スキルによって読み取られる場合、ファイルパスのみを渡し、レビュアー向けに Wiki の内容を要約しないでください。
• Wiki は UTF-8 です。 research-wiki/ をプラットフォームや共同作業者間で移植可能な状態に保つため、すべての Wiki ファイルは UTF-8 で読み書きされます。UTF-8 以外のロケール（中国語版 Windows の cp936 など）で古い ARIS によって作成された Wiki は、一度 UTF-8 に変換する必要があります。まずバックアップを取り、ヘルパーが推測するのではなく、問題のあるファイル名を報告します。

謝辞

Karpathy's LLM Wiki に着想を得ています — 「知識は一度コンパイルして最新の状態に保ち、クエリのたびに導き出し直さない。」