inbox-to-sources

name	inbox-to-sources
description	inbox/ にあるメモを sources/{category}/ にカテゴリ分類して移動し、ファイル名規約とfrontmatterを整え、検証スクリプトでパスを確認するSkill。ユーザーが「inboxを整理して」「inboxをsourcesに移して」「inbox処理して」「メモを取り込んで」のように依頼したら必ずこのSkillを使うこと。wiki/ 側の整理は対象外で、移動と原資料層の整備のみを行う。

inbox-to-sources

inbox/ のメモを sources/{category}/ へ取り込み、原資料層を整える。 wiki/ 側の整理 (テーマ別ページ、リンク、index、changelog) はこのSkillの範囲外。

最初に inbox/ 直下を確認し、.md が1件も無ければ「取り込み対象がない」と報告して終了する。 --dry-run が指定された場合は、手順1〜2 (現状確認と計画) だけを行い、移動計画 (移動元 → 移動先の一覧) とfrontmatterの変更予定を提示して終了する。ファイルの移動・編集は一切行わない。

不変条件

• 分解禁止：1つのメモを複数ファイルに分けない。複数テーマが混ざったメモも1ファイルのまま運ぶ。テーマ分解は wiki/ 側でやる。
• 本文編集禁止：frontmatterだけが編集対象。本文 (frontmatter以下) は1バイトも触らない。タイポも画像の相対パスも書き換えない。
• 画像の相対パス維持：本文が images/xxx.png のように参照しているなら、画像も同じ階層関係の images/ に置く必要がある。
• 移動は git mv：単純な mv だと history が切れる。

カテゴリの決め方

sources/ 直下のカテゴリ構成は固定ではない。新規メモを取り込むとき、必要なら既存ディレクトリの新設・統合・改名や、既存mdの移動もしてよい。

まず sources/ 直下と各ディレクトリの中身で現状を確認する。 新規メモがどこに入るかを考えるついでに、既存の分類が今のメモ群と合っているかも見直す。 構成を変える場合は、その理由 (例：新メモを足したらカテゴリAの粒度が他と揃わなくなった) を報告に添える。

判断の指針は次の通り。

• 既存カテゴリで素直に収まるなら、構成は変えない。新メモを既存に追加するだけにする。
• カテゴリは出所ではなく内容 (トピック) で決める。AI回答による下調べや未検証の調査メモも、明確なトピックがあれば該当カテゴリに入れる。AI回答であることは frontmatter の model で区別でき、未検証の調査メモとして扱う点は変わらない。
• sources/ideas/ は、特定トピックに収まらないアイデア・仮説のためのカテゴリとして使う。
• 1ファイルしか入らないカテゴリを濫造しない。misc/ のような無情報カテゴリも作らない。
• 既存mdを動かすときも git mv を使う。本文編集禁止と画像の相対パス維持は変わらない。
• 大規模な再編成 (5ファイル以上の移動、カテゴリの統廃合) になりそうなときは、計画を立ててユーザーに確認する。

手順

1. 現状を読む

inbox/ 直下のMarkdown、inbox/images/、既存の sources/ 配下のカテゴリを確認する。 各 inbox メモを読み、テーマと既存frontmatterの有無を確認する。 inbox/images/ に画像があれば、本文がどの画像を参照しているかを先に把握する。

2. 配置先と新ファイル名を決める

各ファイルについて次を決める。

• カテゴリ：上の指針に従って決める。
• 新ファイル名：YYYY-MM-DD_slug.md 規約。
  • 日付：元ファイル名に日付があればそれを使う (YYYYMMDD_ 形式はハイフン区切りに直す)。なければ本文中のメタデータ (例：Scraped at: 2026-06-16) を使い、それもなければ inbox 投入日を使う。
  • slug：ファイル名後半をベースにする。check_sources.py の正規表現は .+ なので、日本語・スペース・大文字も許容される。kebab-case化は強制しない。

3. 画像と一緒に動かす

メモが参照している画像は、同じカテゴリの images/ に揃える。 1つの画像を複数カテゴリのメモが共有していたら、画像の複製ではなく、メモのカテゴリ判定を見直して同じカテゴリに寄せる。

4. git mv で移動

配置先カテゴリのディレクトリを作り、メモと必要な画像を git mv で移動する。 画像を移動するときは、本文中の相対パスが壊れない配置にする。

5. frontmatterを整える

_template/source.md に従い、frontmatterを整える。 必須キーは title / created / updated の3つ。 既存frontmatterに model がある場合だけ、任意の出所メタデータとして保持する。 model がないファイルに推測で追加しない。

---
title: "<title>"
created: "<YYYY-MM-DD>"
updated: "<YYYY-MM-DD>"
model: "<model>"
---

• title は内容に沿った題名にする (日本語可)。既存frontmatterの title が内容に合っていればそのまま引き継ぐ。ファイル名との一致は求めない。
• created はファイル名の日付と一致させる。
• updated は既存frontmatterの updated/update を引き継ぐ。なければ created と同じ値にする。
• model は既存frontmatterにある値をそのまま引き継ぐ。空なら残さない。
• 旧frontmatter (例：tags, category, date, update, type, emoji, topics, published) は削除する。title/created/updated/model 以外は残さない。frontmatterブロック全体を新しい内容に置換する。
• frontmatterがない場合は、本文の最初の数行を含めた old_string を作り、その直前に新frontmatterを挿入する。空ファイルだけは Write で作り直してよい。

本文には触らない。

6. 検証

scripts/check_sources.py を実行する。 ruff風に path:line: [SRCNNN] message の形式で出力される。エラーが出たら該当ファイルだけ直す。よく当たるコードは次の通り。

• [SRC003] <key> がありません → 必須キー (title/created/updated) のどれかが欠けている。
• [SRC006] ファイル名が YYYY-MM-DD_slug.md 形式ではありません → ファイル名を整える。
• [SRC007] ファイル名の日付とfrontmatterの created が一致しません → created をファイル名の日付に合わせる。

7. inbox の状態を確認

inbox/ に .gitkeep と images/ だけが残っていることを確認する。 inbox/images/ も中身が空なら .gitkeep だけになっているはず。 .gitkeep まで消してはいけない。inbox は投入箱として残す。

8. 報告

移動先一覧、新設したカテゴリがあればその名前、重複や統合候補が見つかればその指摘を簡潔に伝える。 最後に「wiki/ 側はこのSkillの範囲外」と1行添える。

判断に迷う場面

• 同じ話題のメモが複数ある：統合せず両方残す。区別が必要ならファイル名で分ける (例：_inbox サフィックス)。統合判断は wiki/ 側でやる。
• アイデアとAI下調べが混ざっている：内容のトピックで判定し、1ファイルのまま移す。トピックが定まらなければ sources/ideas/ に入れる。本文に未検証である旨を追記しない。
• 巨大なログ・スクレイピング結果：そのまま移す。圧縮や抜粋への置き換えも分解禁止にあたる。
• 本文が空のメモ：frontmatterだけの状態で sources/ に置く。後で本人が書き足す前提。
• リポジトリの運用メモに見えるもの：ユーザーが「整理対象」と言っていれば sources/ に入れる。判断に迷ったらユーザーに確認する。

避けること

• 単純な mv を使う。
• 本文のタイポ修正、コードブロックの整形、画像パスの書き換え。
• frontmatter以外の追記 (例：「## このメモについて」のような解説の挿入)。
• 寄せ集めだからと複数ファイルに分解する。
• wiki/index.md や wiki/changelog.md の更新。
• inbox/.gitkeep まで消す。