知識ベース運用ワークフロー（LLM Wiki モード）
位置づけと適用
本 Skill はプラットフォーム非依存の方法論です。外部知識をエージェント実行時に呼び出せる行動ルール（Memory/規範/Skill）に変換します。知識ベースは単なるブックマークではなく、エージェントの能力成長エンジンです。各取り込み知識は必ず蒸留され、その価値を判断する唯一の基準は「それがエージェントの具体的なシナリオにおける行動決定を直接変えられるかどうか」です。
- プロジェクトに既存の知識ベース規範ファイル（例：
プロジェクト規範.md）がある場合、それを権威ある参照とし、競合する場合はプロジェクト規範を優先します - 別のプラットフォーム/プロジェクトに適用する場合、本 Skill の3層アーキテクチャとフローに従って実装し、ディレクトリ名はローカライズ可能です。このリポジトリの
examples/には、そのまま実行できる最小限のサンプルが含まれています
3層アーキテクチャ
| 層 | 推奨ディレクトリ | 性質 |
|---|---|---|
| Raw Sources | raw_sources/（記事/議論/動画） | 読み取り専用、収集後は変更不可 |
| The Wiki | knowledge_base/（目次.md、収集経験.md、操作ログ.md） | LLM が管理する派生コンテンツ |
| The Schema | プロジェクト規範.md + プログラムファイル/設定/ | 人間とLLMが共同で管理 |
重要な原則: 元のファイルは常に Raw Sources に残し、Wiki には移動しません。検証に合格した後、目次.md に参照を追加することで「取り込み済み」とみなします。
役割の分離（厳守必須）
| 役割 | 実体 | 責任 | 禁忌 |
|---|---|---|---|
| Planner | 人間 | 収集目標の設定、価値契約の定義、分析の方向付け | ファイルを直接操作しない |
| Generator | LLM | 収集の実行、メタデータの補完、要約の作成、目次とログの管理 | 自身の出力品質を自己評価することを禁止 |
| Evaluator | 検証ツール（例：scripts/validate.py） | フォーマット、エンコーディング、メタデータ、相互参照を独立して検証 | 生成には関与しない |
核となるルール: モデルは自分自身に点数をつけてはいけません。 価値評価は Generator が操作ログに記録し、検証の合格/不合格は Evaluator が判断します。人間が異議を唱えた場合は、人間の判断を優先します。プロジェクトにツールがない場合、リントの6軸に従って人手で1項目ずつ確認しますが、結論は依然として生成者自身が証明することはできません。
Ingest（取り込み）
以下のチェックリストをコピーして進捗を追跡します。
- [ ] 1. 収集前の価値契約（3つの質問）
- [ ] 2. 収集とメタデータの補完
- [ ] 3. コンテンツの読み取り、キー情報の抽出
- [ ] 4. 価値判断（基準に満たない場合は中断）
- [ ] 5. 目次.mdの更新（要約 + 相互参照）
- [ ] 6. 操作ログへの追記
- [ ] 7. 蒸留評価と展開状況のマーク
- [ ] 8. Git コミット
ステップ 1 · 収集前の価値契約 — 着手前に3つの質問に答え、記録します。
- この記事はどの問題を解決するのか？既存の知識との関係は？（補足/比較/拡張）
- どのような条件で「価値がある」とみなすか？少なくとも1つを満たす必要があります：新しい概念の導入、比較の視点の提供、直接的な実践的参考例の提示
- どの階層の
目次.mdに分類されることが期待されるか？（基礎理論/アーキテクチャパラダイム/エンジニアリングプラクティス/ツールとリソース/コミュニティ動向）
ステップ 2 · 収集とメタデータ — 現在のプラットフォームの収集エンジンを使用して原文を取得し（「収集エンジンの抽象化」を参照）、Raw Sources の対応するサブディレクトリに保存します。ファイル名は {source}_{topic}_{date}.{ext} 形式に従います（例：github_karpathy_llm_wiki_20260630.md）。必須メタデータフィールド：URL、収集時間、収集コマンド；推奨フィールド：By、Site、Published、元のソース。収集エンジンは通常、一部のフィールドしか自動抽出できないため、残りは補完する必要があります。
ステップ 4 · 価値判断（中断を含む） — ステップ1の契約と照らし合わせて評価します。いずれの価値条件も明らかに満たさない場合（内容が空虚、重度の重複、知識ベースの目的に無関係）、操作ログに明示的に中断理由を記録して終了し、無理に取り込みプロセスを完了しません。
ステップ 6 · 操作ログのフォーマット：## [日付] ingest | タイトル（追記のみ）。
ステップ 7 · 蒸留評価 — このエントリには、エージェントの動作を直接ガイドできるアトミックなルールが含まれていますか？
| マーク | 意味 | アクション |
|---|---|---|
| 🟢 展開済み | 実行可能なアトミックルールがある | 抽出して Memory/規範/Skill に書き込み、目次.md のエントリに Memory のタイトルを記載 |
| 🟡 部分的に展開 | 一部ある | 展開済みと未展開の具体的な内容とその理由を記載 |
| 🔵 参考索引 | 実行可能なルールなし | 操作ログに理由を簡潔に記載 |
蒸留基準：ルールは、抽象的な理念や参照情報ではなく、エージェントの具体的なシナリオにおける行動決定を変えられるものでなければなりません。
クロスプラットフォーム蒸留対応: Qoder では、蒸留産物を Memory システムに書き込みます（方法論→task_experience、失敗事例→common_pitfalls_experience、アーキテクチャ決定→important_decision_experience などの分類）。他のエージェントプラットフォームでは、そのプラットフォーム自身の永続メモリ/行動ルールメカニズムにマッピングし、判定基準と3色マークは変更しません。
ステップ 8: git add -A && git commit -m "ingest: タイトル"。
Query（照会）
- 最初に
知識ベース/目次.mdを読み、関連するページを特定します - 関連するファイルを詳細に読み、回答を総合します
- 優れた回答は新しいページとして書き戻します — 探索自体にも複利効果を生み出します
- 操作ログに追記：
## [日付] query | 質問 - 新しいページを作成した後：
git add -A && git commit -m "query: 質問"
Lint（検査）
プロジェクトの検証ツールを優先的に実行します（このリポジトリはゼロ依存のサンプルを提供：python scripts/validate.py <知識ベースルートディレクトリ>）。ツールの判定が手動による判断より優先されます。ツールがない場合は、6軸に従って1項目ずつ確認します。
- メタデータの完全性 — 必須フィールド（URL、収集時間、収集コマンド）がすべて揃っているか
- エンコーディングの正確性 — 二重エンコードによる文字化け、BOM、置換文字（U+FFFD）
- フォーマットの規範性 — Markdown は H1 で始まり、メタデータと本文が
---で区切られていること；JSON は_metadataフィールドを持っていること - 命名規範 —
{source}_{topic}_{date}パターンに従っているか - 相互参照 —
目次.mdのリンクが実際のファイルを指しているか；孤立ページの検出 - ソース検証 — URL がソースのホワイトリストに含まれているか
操作ログに追記：## [日付] lint | 検査範囲；修正があった場合は git commit -m "lint: 検査範囲"。
ツールの段階的削減: ツールとプロセスはモデルの弱点を補う補助メカニズムであり、モデルの進歩に伴って単調減少させる必要があります。Lint のたびに確認する：どの検証ルールがもはやトリガーされなくなったか？どのステップをモデルが内面化したか？それらを削除します。
収集エンジンの抽象化（クロスプラットフォーム対応）
コアフローはいかなる収集ツールにも依存せず、収集エンジンはプラットフォームの可用性に応じて選択します。
| プラットフォーム環境 | 収集方法 |
|---|---|
| Windows + Edge ブラウザ | AutoCLI：autocli read "URL" -f markdown -o "出力パス"、By/Site/URL を自動抽出；PowerShell では stderr の進捗情報が ExitCode=1 の誤報告を引き起こす可能性があるため、出力に "Saved to ..." が含まれていれば成功とみなす |
| Webページ読み取り機能を持つエージェントプラットフォーム | Web 読み取りツール（WebFetch など）で直接取得し Markdown に変換 |
| 公開 API ソース | Hacker News、Lobsters などはブラウザ不要で、API に直接リクエスト |
| ネットワークツールなし | ユーザーが原文を貼り付け、手動で保存し、収集コマンド は「手動貼り付け」と正直に記録 |
どのエンジンを使用しても、取り込み後のメタデータ、検証、蒸留の要件は完全に同一です。収集コマンド フィールドには、実際に使用したエンジンとコマンド（ダウングレードや切り替えを含む）を正直に記録し、再現性を確保します。
約束事クイックリファレンス
- ファイル名：
{source}_{topic}_{date}.{ext}、source は小文字 - 操作ログ：追記のみ、フォーマット
## [日付] {ingest|query|lint} | 簡単な説明 - コミットメッセージ：
{ingest|query|lint}: {簡単な説明}；初期化：init: 知識ベースベースライン - 失敗から学んだ教訓は構造化して
収集経験.mdに記録し、操作ログに混在させない