media-to-roadmap

/media-to-roadmap — 外部ソースを取り込み、重複のないロードマップを出力

目的はひとつです。AI コーディング、エージェント、開発者のワークフローに関する動画、ポッドキャスト、記事、スレッドが公開され、Ane がその中で採用する価値のあるものを知りたいとします。出力されるのは、現在システムが行っていることと照合済みの、agent-improvements/ 内のロードマップファイルひとつです。

この仕組みがある理由

このパターンは、少なくとも6回、手作業で実施されています。Karpathy/Forte の動画は14項目の登録簿に、Nate Herk/Cole Medin のポッドキャストは9項目のロードマップに、loops の動画（2026-06-21）は監視ループの構築計画に、STORM の動画（2026-06-30）は調査スコーピングスキルに、そして Thariq のコンテキストエンジニアリング記事と Isenberg のグラフエンジニアリング動画（2026-08-04）は、段階的な導入計画になりました。パイプラインは常に同じです。標準化する価値があるのは、何を実装しないかの判断です。ソースは常に誇張するためです（STORM の「90秒＝48時間分の博士課程の作業」という主張が典型例です）。

手順

1. ソースを取得する — 記憶を頼りに作業しない

ロードマップに記載するすべての主張は、取得したコンテンツを根拠とします。ソースの種類ごとの取得手順（POT トークンを使うフォールバックを含む YouTube の文字起こし、記事、ログインが必要な x.com のスレッド）は、references/fetch-patterns.md にあります。context-mode（ctx_fetch_and_index / ctx_execute）経由で取得し、生の文字起こしが会話に含まれないようにしてください。ソースを取得できない場合は中止し、その旨を伝えてください。学習データから内容を再構成してはいけません。

2. 具体的な手法を抽出する

ソースが実際に提案していることを、テーマではなく、具体的で実装可能な主張として列挙します。各主張について、ソース自身が提示する根拠と、それに対する最も強い反論を記録してください。反論を乗り越えた主張は分類できます。乗り越えられなかった主張は、反論を理由として、そのまま「採用しない」リストに入れます。

3. すでにあるものを棚卸しする

何かを分類する前に、システムがすでに何を行っているか確認します。確認対象を、すばやく答えが得られる順に示します。

1. インストール済みスキル — ~/.claude/skills/ の名前と説明。
2. フック — ~/.claude/settings.json。
3. ハーネス — tests/run_tests.py のチェック名。
4. 作業フォルダー内の scripts/ と ane_package/。
5. 常設ルール — ~/.claude/CLAUDE.md とプロジェクトの CLAUDE.md。
6. 専門エージェント — agent-improvements/agent_registry.md。

システムがすでに実装しているアイデアは、新しい作業として再提案せず、すでに実施中に検証結果として記録します。この重複チェックこそが、このスキルの存在理由です。省略すると、バックログのハーネスチェックが検出するために作られた重複項目の増加につながります。

4. 残ったアイデアをすべて分類する

各アイデアを、必須となる2つの軸で分類します。

• 構築方針：再利用 > 改善 > 再構築。 並行する仕組みを作るより、既存のフック、チェック、モジュール、スキルを拡張することを優先します。再利用または改善する対象を明記してください。「新規」とする場合は、既存の仕組みでは対応できない理由を説明します。
• レーダー：Adopt / Trial / Assess / Hold（ThoughtWorks のレーダー方式）：
  • Adopt（採用） — 適合性が実証済みで、リスクが低いもの。指定されたブロックで実施します。
  • Trial（試行） — 有望なもの。システム全体で使う前に、名前を明記した成功判定基準を設け、範囲を限定したワークフローひとつで試験導入します。
  • Assess（評価） — 理解する価値があるもの。スパイク調査または注視項目とし、構築を約束しません。
  • Hold（保留） — 現時点では追求しないもの。その理由を記載します。Hold の項目があることで、次回の調査で同じ議論を繰り返さずに済みます。

5. ロードマップを作成する

対象：agent-improvements/<slug>-YYYY-MM-DD.md。slug はソースから取得します。対象ファイルが存在する場合は、mel_wiki/wiki/concepts/edit-preservation-protocol.md を適用します。必須セクションは次の順序で記載します。

1. Source — 内容／発信者／場所／日付、使用した取得方法、スキャン日。
2. What the source says — 抽出した主張。それぞれに根拠と最も有力な反論を添えます。
3. Already doing — 検証リスト。各項目に既存の適用先を明記します。
4. Adopt / Trial / Assess / Hold — 分類したアイデア。それぞれに実装方法と工数の見積もりを添えます。
5. What NOT to build — 必須です。その理由も記載します。空のセクションは、すべてを作る価値があるという意味ではなく、スキャンに失敗したことを示します。
6. Warning signals — ソース内のどの要素が、後にシステムで見られた場合に、助言が古くなったことを示すかを記載します。
7. Sequenced blocks — Adopt／Trial の項目を、実装可能なセッション単位にまとめ、仕様を定めてから作業を明確に切り分ける形式で記載します。

依頼された場合は、agent-improvements/handoffs/ に継続作業用の引き継ぎ資料も作成します。新しいセッションが、このセッションの文脈なしでブロック 1 を実装できるようにします。

絶対ルール

• 助言の対象をモデルの世代に合わせます。 最先端世代のモデルで実証された手法が、Sonnet 級の専門プロンプトにも自動的に当てはまるわけではありません。ソースがどの世代を使用したか、またその手法を適用できるかを明記します。
• 2 つのチェックを通過していないサードパーティ製オーケストレーションプラットフォームは禁止です。 IPPF デバイスでは管理者権限がなく、SRHR データが非エンタープライズツールに入ることもありません。インストールまたは外部サービスを必要とするアイデアは、Assess から先に進む前に、管理者権限の要件と機密データの要件を確認します。
• 推奨する前に、誇張を取り除きます。 推奨する各項目について、最も有力な反論を明記します（まず疑ってかかる姿勢）。反論を示さずにソース独自のベンチマークの主張を繰り返すのは、品質上の欠陥です。
• システムに関する数値は、記憶ではなく計算で求めます。 ロードマップに記載するチェック、スキル、フックの数は、同じターン内で計算するか、その数を出すコマンドに置き換えます。

重複せず、関連する項目

関連項目	違い
video-content-analysis	MEL 研究動画ファイル（FGD、ウェビナー）を文字起こし＋同意取得のパイプラインに通します。このスキルは公開されている外部コンテンツを読み取ります
/system-audit、/grade-system	システムの内部から調査します。こちらは外部の情報を取り込み、その調査結果をシステムに反映します
/improve-system	内部 QA ログとセッション履歴を掘り起こします。こちらは外部シグナルに対応します
evidence-synthesis	正式な学術的 REA です。こちらはグレーテクノロジーのウォッチコンテンツを扱います
linkedin-field-note	スキャンの結論をフィールドノートのきっかけにできますが、記事の執筆はそのスキルの役割です