surveys

Imported from mlnagoya/surveys (AGENTS.md). Install upstream with npx skills add mlnagoya/surveys. Copyright stays with the author.

Repository Guidelines

プロジェクト構成

• <basename> = <topic>_<arXivID>（例: idefics2_2405.02246）。
• 各 Markdown と同名のアセット用フォルダを併設: 例) UnSAM_2406.20081.md と UnSAM_2406.20081/。
• 画像は相対パスで参照: ![説明](./<md_basename>/image.png)。 例: 20240516_reports/idefics2_2405.02246/fromage.png。
  • レポート本文には意味のある内容を示す画像を複数枚挿入し、ファイル名も内容が推測できるものにする（例: figure1_pipeline.png）。placeholder 等の汎用名やダミー画像は禁止。
  • 画像は原則として対象論文 PDF からの切り抜きを使用し、必要に応じて PyMuPDF 等で適切な領域をトリミングする。
  • 画像と同じディレクトリに coverage_evidence.md を作成し、PDF各ページの網羅性と要約・画像の根拠（ページ番号と引用）を整理する。
• 最終配置のパス規約（重要・要確認）:
  • 最終版の Markdown は日付フォルダ直下に置く（例: 20250918_reports/auras_2509.09560.md）。
  • 同名のアセットフォルダを同じ日付フォルダ直下に併設（例: 20250918_reports/auras_2509.09560/）。
  • 追加のサブディレクトリ（/auras/auras_2509.09560.md のような二重ネスト）は作らない。
  • 画像参照は ./<md_basename>/...（例: ./auras_2509.09560/fig1.png）。

ビルド・プレビュー・開発

• ビルドは不要。任意のエディタ/ビューアで Markdown を開いて確認。
• 便利なコマンド例:
  • レポート一覧: find . -maxdepth 2 -type d -name '*_reports'
  • 文字列検索: rg -n "keyword" 2025* 2024* 2023*
  • ツリー表示: tree -L 2 2024*（tree がある場合）

スタイルと命名規約（n-kats 準拠）

• 先頭3行の書式:
  1. H1 に論文タイトル 2) arXiv URL 3) (まとめ @github_id)。
• 著者情報: 先頭3行の直後に「著者」セクションを置き、arXiv もしくは PDF の記載に従って著者名を箇条書きで列挙（所属は任意、外部リンクは最小限）。
  • 著者表記ルール: 人名はアルファベット表記のみ可（原文の arXiv/PDF 準拠）。カタカナ・漢字・和訳は不可。1ファイル内で表記を統一すること。
• 見出しの順序（例）: # どんなもの？ → # 先行研究と比べてどこがすごい？ → # 技術や手法の肝は？ → # どうやって有効だと検証した？ → # 議論はある？ → ## 私見 → # 次に読むべき論文は？。
  • 主要セクションは基本的に # 見出しで統一し、補助的な節を追加する場合は ## 以降の階層を適宜利用（例として「## 私見」）。
• 命名:
  • Markdown: <topic>_<arXivID>.md（例: idefics2_2405.02246.md）。
  • 画像フォルダ: <topic>_<arXivID>/ に配置（例: ./idefics2_2405.02246/arch.png）。
  • 画像名: snake_case.ext、サイズは概ね < 2 MB。
• 箇条書きを優先、1行は約100文字目安。
  • 文中での任意改行は基本的に行わず、1文＝1行を目安とする（Markdown の強制改行用の末尾2スペースは特別な意図がある場合のみ使用）。
• タイトル直後に「著者」セクションを置き、本文は原則として # 見出しをベースにしつつ、必要に応じて ## などの下位見出しを追加する。
• 既存ファイルの更新では cat > file 等の破壊的上書きは避け、apply_patch など差分ベースの編集手段を使う。
• 表記統一（一般）:
  • 用語・語彙は文書内で表記を統一（英語/日本語の混在を避ける）。
  • 英語の技術語は原綴りで統一するか、日本語訳で統一するかを選ぶ（併記はしない）。
  • 日本語表記の注意: 日本語で統一する場合は不自然な直訳・誤用・不慣用な訳語を避け、専門分野で自然な表現を用いる。適切な日本語がない場合は英語原綴りを採用。
  • 数値・単位・半角/全角・句読点（、。）の使い方を統一。
  • 略語は初出で展開し、以降は略語に統一（例: Key-Value → KV）。

人間まとめスタイル（n-kats版）ルール

• 全体スタイル

  • 日本語ベース、技術用語・モデル名は原語のまま（VLM, RAG, GPT-4 など）。
  • 長文よりも「短い文×段落／箇条書き」で区切る。1文はなるべく 1 アイデア。
  • 図は本文の流れの中で軽く言及する程度にとどめる（詳細説明はしない）。
  • 「何をしたか・何が新しいか・何がわかったか」を中心に、自分が重要だと思う部分だけを厚めに書く。重要でない実験や枝葉の ablation は切り捨ててよい。

• # どんなもの？

  • 分量: 2〜4 文程度（1〜3 段落）。箇条書きにする場合も 2〜3 個まで。
  • 内容:
    • 1文目: 扱っている問題・テーマ（対象・目的）を一言で書く。
    • 2文目: おおまかなアプローチ／枠組み（新しい評価フレームワーク、新手法など）を書く。
    • 3文目（あれば）: 代表的な成果・結論を一言で書く。
  • データセット数・パラメータ数などの細部は基本ここでは書かない。読者が「どんな種類の論文か」を即座に把握できればよい。

• # 先行研究と比べてどこがすごい？

  • 分量: 3〜5 行程度。必要なら 2〜4 個の箇条書き。
  • 「従来は○○だが、この論文は△△」という対比構文を必ず1つ以上含める。
  • 位置づけの観点は 1〜3 個に絞り、AGIEval / KOLA / 既存 RAG など代表名＋一言説明で役割だけ伝える。
  • 数式・指標定義などの詳細はここには書かない。

• # 技術や手法の肝は？

  • 分量: 最も厚くなってよい章。全体でおおよそ 10〜30 行まで許容。
  • 冒頭に 1〜3 行で全体フロー／構造（例: 準備段階と推論段階、二段構成など）を書く。
  • その後、自分が重要だと思う論点ごとに小見出し（例: 「実験一覧」「メタアーキテクチャ」「○○の効果は？」）を立てる。
  • 各小見出しは 1〜3 段落＋必要なら箇条書き程度に抑え、図は「パイプライン図」「スコア比較」など内容レベルの説明にとどめる。
  • プロンプトや評価式は「××の観点を評価するプロンプト」「○○を重視する指標」と要約して書き、全文引用は別途に任せる。

• # どうやって有効だと検証した？

  • 分量: 中くらい。5〜15 行程度を目安にする。
  • 内容:
    • どのデータを使ったか。
    • どんな比較条件があるか。
    • 何を指標にしたか。
    • 結果としてどういう傾向が出たか。
  • 数値は「壊滅的」「かなり大きい差」「おおむね 70〜80%」などのざっくり表現＋代表値にとどめる。
  • 表・図の全パターンは追わず、重要だと思う結果だけを拾い、「だから何が言えるか」を 1〜2 行で必ず付ける。

• # 議論はある？

  • 分量: 2〜6 行程度。
  • 著者の議論（示唆・限界・今後）のうち、勉強会で押さえたいポイントだけ抜き出す。
  • 「この評価の範囲はここまで」「この設定にはこういう限界がある」といった制約の一言を含める。
  • 細かい実験の感想より、「論文として何を主張しているか／どこが弱いか」に集中する。

• ## 私見

  • 分量: 2〜4 行程度。
  • 自分の感想・直感・違和感を書く場所。少し砕けた言い回しや軽い小ネタも許容する。
  • 事実ではなく評価・感情を書く。事実の説明は上の章で済ませる。

• # 次に読むべき論文は？

  • 分量: 1〜3 本の箇条書き。
  • 各論文について、タイトル（もしくは略称）＋「何の観点で関連しているか」を 1 行程度で書く。
  • 説明文を長く書かず、「名前を見て思い出せる」レベルを目指す。

• AI が人間スタイルを真似るときのチェックポイント

  • # どんなもの？ は短く（2〜4 文）に抑える。
  • 各章で「自分が重要だと思う観点」を優先して厚く書き、他は捨てる（網羅しない）。
  • 図表・プロンプト・指標の詳細は代表例だけにし、原文に戻れば分かる粗さで止める。
  • 感想やメタなコメントは主に # 議論はある？ と ## 私見 に集約する。

レポート本文をAIが全て書く場合のルール（n-katsスタイル拡張）

• 目標

  • AI がレポート本文を最初から最後まで生成する場合でも、既存の n-kats レポートと同じ読み味を保つ。
  • 人間まとめスタイルをベースにしつつ、AI の強み（構造整理・条件列挙・指標定義・関連論文の拾い上げ）を活かして「ストーリー＋技術メモ」を一体で書く。

• 共通スタイル

  • 日本語で書き、技術用語・モデル名は原語のまま（VLM, RAG, GPT-4 など）。
  • 箇条書き主体・短い文主体。1文＝1アイデアを基本にする。
  • 全章を通して、「何をしたか・何が新しいか・何がわかったか」＋「どういう条件でそう言えるか」のペアを書くことを意識する。

• # どんなもの？

  • 役割: テーマ・アプローチ・ざっくりした結果が一読で分かること。
  • 分量: 2〜4 文（または 2〜3 箇条書き）。
  • 書き方:
    • 1文目: 扱う問題／テーマ（対象・目的）を一言で。
    • 2文目: アプローチ／枠組み（新しい評価フレームワーク・新しいRAG・新しいリテラシーなど）。
    • 3文目（あれば）: 代表的な成果・結論を一言で。
  • 固有名（AINSTEIN, GraphRAG など）は 1〜2 個だけ出し、細かい条件や指標名は後の章に回す。

• # 先行研究と比べてどこがすごい？

  • 役割: 既存は何を評価／解決してきたか、本論文はどこをずらしているかを明確にする。
  • 分量: 3〜6 行程度。
  • 書き方:
    • 「既存研究は A を評価していたが、この研究は B に特化している。」など、対比構文を必ず 1 つ以上含める。
    • 代表的ベンチマークやツールを「名前＋一言役割」で整理する（例: 「AGIEval: 一般試験で “問題を解く力” を測るベンチマーク。」）。
    • リストは 2〜4 個にとどめ、一覧表にならないようにする。

• # 技術や手法の肝は？

  • 役割: パイプラインやアーキテクチャ、重要な設計判断を整理して示す。
  • 分量: 10〜30 行程度まで許容（章内で最も厚くてよい）。
  • 書き方:
    • 冒頭に 1〜3 行で全体フロー（例: 準備段階と推論段階、Generalizer/Solver の二段構成など）を書く。
    • その後、小見出し＋箇条書きで構造化する（例: 「実験一覧」「アーキテクチャ」「○○の効果は？」）。
    • 各小見出しで、何を変数にして何を比較しているか、重要な条件ラベルや指標名（C0〜C3, TS, SS, IFR, CR/AT, Comprehensiveness など）を正式名称＋簡単な定義でまとめる。
  • 注意:
    • プロンプト全文や数式は載せず、「××の観点を評価するプロンプト」「○○を重視する指標」と要約する。
    • 図の内容を行単位で再現せず、「パイプライン図」「成功率一覧」「クラスタ可視化」など何を見せている図かだけを書く。

• # どうやって有効だと検証した？

  • 役割: どんなデータ／条件で、何を指標に、どういう結果パターンが出たかをまとめる。
  • 分量: 5〜15 行程度。
  • 書き方:
    • 実験設定を整理する（データセット名＋一言、条件ラベルと意味、評価指標の定義を 1 行ずつ）。
    • その上で、結果のパターンを短くまとめる（例: 「GraphRAG は Comprehensiveness/Diversity で有利だが Directness には弱い。」）。
    • 数値は代表値をざっくり（「70〜80%前後」「20%以下」など）にとどめる。

• # 議論はある？

  • 役割: 著者の Discussion / Limitations / Future Work から重要な論点だけを抽出する。
  • 分量: 3〜6 行程度。
  • 書き方:
    • 結果の意味づけを 2〜3 個のパターンに整理する（例: 内部批評モデルがボトルネック、包括性と直接性のトレードオフなど）。
    • データ領域の偏りや LLM-as-a-judge 依存など、制約やバイアスを 1〜2 行でまとめる。

• ## 私見

  • 役割: 読者にとっての読みどころや怖さ／面白さを短く共有する。
  • 分量: 2〜4 行程度。
  • 書き方:
    • 「こう感じる／こうなりそう」というスタンスを書く（例: 「そのうち人間が評価される側になりそう。」）。
    • 多少くだけた表現や小ネタも許容するが、事実と感想を混ぜない。「〜かもしれない」「〜と感じる」とクッションを入れる。

• # 次に読むべき論文は？

  • 役割: この論文が刺さった読者が次に読むとよい文献を示す。
  • 分量: 1〜3 本の箇条書き。
  • 書き方:
    • AI の関連論文探索能力を使いつつ、最終的に 1〜3 本に絞る。
    • 各論文について、「どの観点で関連が深いか」を 1 行で説明する（例: 「LLMの問題解決能力を俯瞰するサーベイ。」）。

• チェックリスト（AI用）

  • # どんなもの？ は 2〜4 文に抑えたか。
  • # 先行研究と比べてどこがすごい？ に「従来 vs 本論文」の対比が最低1つあるか。
  • # 技術や手法の肝は？ に、パイプライン全体説明＋主要コンポーネント＋重要な条件・指標名が整理されているか。
  • # どうやって有効だと検証した？ で、データ・条件ラベル・指標定義・結果パターンが過不足なくまとまっているか。
  • # 議論はある？ で、示唆と限界が 2〜3 個に圧縮されているか。
  • ## 私見 に、筆者のスタンスが 2〜4 行で明確に書かれているか。
  • # 次に読むべき論文は？ が 1〜3 本に絞られ、各 1 行コメントが付いているか。

テスト/品質確認

• 各レポートで手動確認:
  • 画像が表示される（相対パスのみ）。
  • 参照リンクが解決する。外部直リンクは極力避ける。
  • 大文字小文字の不一致がない。
  • 著者セクションがあり、表記揺れや欠落がない。
• 任意ツール: markdownlint '**/*.md'、リンクチェッカー等。
• 例外: エージェントの草案（_tmp/配下）はプレースホルダ画像の記述を許容（後続PRで実画像に差替/削除）。
• プレースホルダを最終要約に残す場合: alt/キャプションに「想定」を明記し、リンク切れは許容（後続PRで実画像を追加）。

コミット/PR ガイドライン

• コミットは現在形＋スコープ接頭辞:
  • report: add 20241017 patchcore summary
  • assets: compress blip2 figures
  • docs: fix links in 20240321 README
• PR には以下を含める:
  • 変更概要と影響パス、必要に応じてプレビュー画像。
  • 課題リンク（あれば）とチェックリスト（画像/リンク/ファイル名確認）。
  • n-kats 準拠かの確認（先頭3行・見出し順・相対パス）。

セキュリティ/アセット

• 画像の EXIF 等のメタデータは必要に応じて除去。
• 図や本文、ファイル名に機微情報を含めない。
• 図は可逆圧縮を優先。軽量であればソース（例: *.drawio）も保存。

エージェント向け指示（役割と手順）

• 既定言語: 基本的な応答は日本語。

• 中間成果物:

  • レポート本文・coverage_evidence は _tmp を使わず最初から最終配置パスに直接作成する（移動前提のドラフトを _tmp/ に置かない）。
  • それ以外の一時ファイル（HTML 取得結果・スクリプト・ログなど）は _tmp/ を利用し、PR に _tmp/ を含めない。

• 日付の決定: connpassで次回「機械学習名古屋研究会」の開催日を確認し、フォルダ日付に使用。

  • サイト取得（推奨）: 検索結果を降順（sort=2）で取得し、_tmpに保存して解析。
    • mkdir -p _tmp
    • curl -fsSL -A 'Mozilla/5.0' 'https://connpass.com/search/?q=機械学習名古屋研究会&select=upcoming&sort=2' -o _tmp/connpass_search_sorted.html
    • 解析（未来で最も近い日を出力）:
      • python3 - << 'PY'\nimport re,sys,datetime; from pathlib import Path\nht=Path('_tmp/connpass_search_sorted.html').read_text(errors='ignore')\niso=re.findall(r'(20\\d{2}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}Z)',ht)\njp=re.findall(r'(20\\d{2})/(\\d{1,2})/(\\d{1,2})',ht)\nnow=datetime.datetime.now(datetime.timezone.utc); cand=[]\nfor s in iso:\n try:cand.append(datetime.datetime.fromisoformat(s.replace('Z','+00:00')))\n except:pass\nfor y,m,d in jp:\n try:cand.append(datetime.datetime(int(y),int(m),int(d),tzinfo=datetime.timezone.utc))\n except:pass\nassert cand,'NO_DATE_FOUND'\nfuture=[c for c in cand if c>=now]; ch=min(future) if future else max(cand)\nprint(ch.strftime('%Y/%m/%d'))\nPY
  • API（参考）: curl -s 'https://connpass.com/api/v1/event/?keyword=機械学習名古屋研究会&count=1&order=2' | jq -r .events[0].started_at
  • シリーズIDが判明している場合は series_id を優先（安定）。
  • 取得結果に不確実性がある場合、必ず手動でページを確認。

• 論文取得（環境作成）:

  • uv venv .venv && source .venv/bin/activate
  • 必要に応じて取得/解析ツールを導入: uv pip install arxiv httpx lxml など。
  • uv が未インストールの場合のフォールバック:
    • python3 -m venv .venv && . .venv/bin/activate
    • pip install -U pip setuptools wheel && pip install arxiv httpx lxml
    • 判定例: command -v uv >/dev/null || echo 'uv not found'

• 要約作成（n-kats準拠）:

  • 先頭3行・見出し順を踏襲。画像は扱えない前提で、想定図のプレースホルダを本文に挿入（例: ![図1 想定: アーキテクチャ図](./<basename>/fig1_placeholder.png)）。
  • arXiv/PDF から著者名を抽出し、「著者」セクションを3行目の直後に追加。
  • この段階では README.md を作成しない（別PRで作成）。
  • アブストラクトだけでなく、必ず PDF をダウンロードして本文を確認のうえで要約を作成する。
  • 論文全体の利用: 要約作成時は PDF の全文（必要に応じて付録を含む）を根拠として記述する。アブストラクトのみでの作成は禁止。
  • 長文時の事前確認: ページ数がおおむね30ページ以上の論文は、要約着手前に担当者へ確認を取り、範囲・粒度・重点項目を合意してから進める。
  • 想定問答（Q&A）は Markdown の本文には入れない（PR コメント等で別途提示）。
  • AI支援ワークフロー（例: Codex CLI 利用時）:
    • 初回ドラフト生成:
      • プロンプト例: https://arxiv.org/pdf/<ID>.pdf についてまとめて など、PDF URL を渡してまず素の要約を生成させる。
      • 可能なら「AGENTS.md のスタイルと、既存の n-kats 要約に倣って」と明示し、見出し構成とトーンを合わせる。
    • 粒度調整:
      • 2回目のプロンプトで「もっと詳しく書いて（2025xxxx_reports/xxx_yyyy.mmdddd.md の書き方を参考に）」のように、既存レポートを具体的に指示し粒度・分量を合わせる。
      • とくに # 技術や手法の肝は？ と # どうやって有効だと検証した？ の厚みを、人間レポートと同程度にするよう明示する。
    • 図・画像への言及:
      • 生成結果で図がほとんど触れられていない場合、「他の図や表にも最低限触れて」と追加指示し、本文に対応するプレースホルダ（fig1/fig2 など）を増やす。
      • 実際の画像切り出し時は、この対応関係をもとにファイル名（例: model_size_vs_hs.png）を決める。
    • ハルシネーション・カバレッジチェック:
      • プロンプト例:
        • 「論文の内容と要約が一致しているか、扱っていない主要な内容がないかを確認してください。PDFのページごとに、そのページの内容を要約内でどう扱ったかを1–2行で説明し、未カバーの重要トピックがあれば最後にまとめてください。」
      • AI の出力は、そのまま該当レポートのアセットフォルダ内 coverage_evidence.md のたたき台として利用し、人間が軽く整形する。
    • 人間による最終確認:
      • 発表や共有前に、少なくとも以下を人間が確認する:
        • イントロ・手法・実験・議論の各セクションで、要約の記述とPDFの内容が大きく食い違っていないか。
        • # 次に読むべき論文は？ などで挙げた論文が実在し、本文中の引用とも整合しているか（ハルシネーション検査）。
        • AI が付録を要約に組み込んでいる場合、重要な補足が落ちていないか。
      • 推奨の読み方: 「初手まとめ作成 → coverage_evidence をベースにハルシネーションチェック → 気になるページだけPDFを精読」という二段階の読み方を基本とする。

• 最終化・配置:

  • レポート本文は作成時点から開催日フォルダ直下に置き、ファイル名は <topic>_<arXivID>.md とする。
    • 例: 20251120_reports/reflecting_with_ai_2511.13046.md
  • 同名アセットフォルダを日付フォルダ直下に用意（例: 20251120_reports/reflecting_with_ai_2511.13046/）。
  • 注意（過去の誤りの反省）: Markdown をトピック名のサブディレクトリに入れない。
    • 誤: 20250918_reports/auras/auras_2509.09560.md
    • 正: 20250918_reports/auras_2509.09560.md

• レビュー観点:

  • 日本語の不自然さ・論理飛躍・用語の一貫性を校正。
  • 想定問答はファイル外（コメントやレビュー用メモ）で用意し、本文に含めない。

• 実務上の注意:

  • すべて相対パス。rg を優先して調査。大きな変更は小さなコミットに分割。

list.md の作成・更新手順（ドキュメント）

• 勉強会インデックス list.md の更新方法は docs/how_to_write_list.md を参照。
  • 回番号の確認、各レポートからのタイトル/リンク/アカウント抽出、ジャンルの付与、重複防止、表形式の記法（同一回の2行目以降は || 始まり）などの手順を記載。
  • 中間ファイルは _tmp/ を使用し、コミットに含めない運用とする。

依存コマンドの取得（_cache/bin）

• 原則: 足りないコマンドはリポジトリ直下の_cache/binに配置し、PATHを通す。
  • 準備: mkdir -p _cache/bin && export PATH="$PWD/_cache/bin:$PATH"
• uv（なければ）:
  • curl -fsSL https://astral.sh/uv/install.sh | sh -s -- --install-dir _cache/bin
• jq（なければ, Linux x86_64想定）:
  • curl -fsSL -o _cache/bin/jq https://github.com/jqlang/jq/releases/latest/download/jq-linux-amd64 && chmod +x _cache/bin/jq
• ripgrep/rg（なければ, Linux x86_64想定）:
  • ver=$(curl -fsSL https://api.github.com/repos/BurntSushi/ripgrep/releases/latest | jq -r .tag_name)
  • curl -fsSL -o /tmp/rg.tgz https://github.com/BurntSushi/ripgrep/releases/download/$ver/ripgrep-$ver-x86_64-unknown-linux-musl.tar.gz
  • tar -xzf /tmp/rg.tgz -C /tmp && mv /tmp/ripgrep-*/rg _cache/bin/rg && chmod +x _cache/bin/rg
• tree の代替: findで代用可能（例: find 2024* -maxdepth 2 -type d | sed 's|[^/]*/| |g'）。
• 注意: _cache/はローカル専用。コミットやPRには含めない。

Codex/MCP 設定（fetch サーバの追加）

• 目的: エージェントがHTTP取得を行えるよう、MCPのfetchサーバを有効化。
• 手順:
  1. Nodeがあれば npx を使う。なければ _cache/bin に Node/npm を用意するか、手動で実行環境を整える。
  2. .codex/config.example.json をCodex CLIの設定として利用。
     • リポジトリ直下の.codex/config.jsonを参照するクライアントの場合: 例をコピー
       • cp .codex/config.example.json .codex/config.json
     • 別パスの設定を参照するクライアントの場合: 既存設定のmcpServersに以下を統合
       • "fetch": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-fetch"] }
  3. 必要に応じてPATHに_cache/binを追加。
• 備考: Pythonのみの環境では代替が未整備のため、Node/npm（npx）の用意を推奨。

ユーザー情報の扱い（担当者名）

• 保存場所: _cache/user.md（PRやコミットに含めないローカル情報）。
• フォーマット（例）:
  • シンプル: username: n-kats の1行のみ。
• 利用箇所: 各要約の3行目 (まとめ @<username>) に反映。
• 取得手順:
  • 存在確認して未検出なら、対話で「担当者名（GitHub/ハンドル）を教えてください」と質問し、作成。
  • 作成例: mkdir -p _cache && printf 'username: %s\n' "<NAME>" > _cache/user.md
• 注意: _cache/user.md はローカル専用（.gitignore 済み）。レビュー/PRでは参照のみで内容は提出しない。