| 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 まで消す。
