knowledge-intake

ナレッジの取り込み

外部リソースをナレッジストアに取り込みます。ユーザーが記事、ブログ投稿、論文へのリンクを共有したとき、このスキルは評価、保存の判断、適用先への振り分けを支援します。

使用する場面

• セッションで得たナレッジを記録して整理するとき
• 情報を構造化されたメモリーパレスに取り込むとき

使用しない場面

• 長期保存が不要な一時的なメモ
• ナレッジの記録が不要な、コードのみの変更

概要

あらゆる外部リソースについて、次の3つの問いに答えるナレッジガバナンスフレームワークです。

1. 保存する価値はあるか？ - シグナルとノイズの比率、関連性を評価します
2. どこに適用するか？ - ローカルのコードベースまたはメタインフラストラクチャに振り分けます
3. 何に取って代わるか？ - 削除すべき古いナレッジを特定します

取り込みのシグナル

ユーザーが外部リソースへのリンクを共有することは、それが重要であるというシグナルです。

共有するという行為は、そのリソースがユーザー自身のフィルターを通過したことを示します。私たちの役割は次のとおりです。

• 重要なパターンや知見を抽出する
• 適切な保存先と形式を判断する
• 既存のナレッジ構造と結び付ける
• 適用できる機会を特定する

クイックスタート

ユーザーがリンクを共有したとき：

1. FETCH    → Detect format, retrieve and convert content
2. EVALUATE → Apply importance criteria
3. DECIDE   → Storage location and application type
4. STORE    → Create structured knowledge entry
5. VALIDATE → Scribe verification (slop scan + doc verify)
6. CONNECT  → Link to existing palace structures
7. PROMOTE  → Offer Discussion promotion (score 80+)
8. APPLY    → Route to codebase or infrastructure updates
9. PRUNE    → Identify displaced/outdated knowledge

ステップ 1：形式を検出して FETCH する

コンテンツを取得する前に、URL またはファイルパスからソースの形式を検出し、適切な取得方法を選びます。

ウェブ記事およびブログ投稿（デフォルトの方法）： WebFetch を使って HTML コンテンツを直接取得します。 変換は不要です。

ドキュメントの URL（PDF、DOCX、PPTX、XLSX）： leyline:document-conversion プロトコルを適用します。 まず markitdown MCP ツールで高品質な Markdown への変換を試み、次にネイティブの Claude Code ツール（PDF の場合は Read など）にフォールバックします。その後、markitdown がなく、形式がサポートされていない場合はユーザーに通知します。

ローカルファイル（ユーザーがファイルパスを共有した場合）： 絶対パスから file:// URI を作成し、 leyline:document-conversion プロトコルを適用します。

形式の検出ヒューリスティクス：

URL パターン	形式	取得方法
*.pdf、arxiv.org/pdf/*	PDF	document-conversion
*.docx、*.doc	Word	document-conversion
*.pptx、*.ppt	PowerPoint	document-conversion
*.xlsx、*.xls	Excel	document-conversion
*.epub	電子書籍	document-conversion
drive.google.com/*	さまざまな形式	document-conversion
その他すべて	HTML／ウェブ	WebFetch（既存）

取得方法にかかわらず、取得後は leyline:content-sanitization に従ってコンテンツを外部コンテンツの境界マーカーで囲んでから、ステップ 2（EVALUATE）に進みます。

ステップ 5：Scribe による検証（必須）

ナレッジコーパスのすべてのエントリーは、確定する前に Scribe による検証に合格する必要があります。

新しいエントリーに対して Skill(scribe:slop-detector) を実行します。

• スコアは 2.5 未満（「問題なし」から「軽微」）である必要があります
• Tier 1 のマーカー（delve、tapestry、comprehensive、leveraging など）がないこと
• 1,000 語あたりのヘッジ語の密度が 15 未満であること

Agent(scribe:doc-verifier) を使って次を検証します。

• すべてのファイルパスと URL が存在すること
• すべての相互参照が有効であること
• 出典の帰属が正確であること

# Quick validation for knowledge corpus entry
/slop-scan docs/knowledge-corpus/[entry-name].md
# Doc verification is now agent-only:
Agent(scribe:doc-verifier) "Verify docs/knowledge-corpus/[entry-name].md"

スロップスコアが 2.5 を超えるエントリーは確定しないでください - 具体的な詳細を加えて書き直します。 検証： --help フラグを付けてコマンドを実行し、利用可能であることを確認します。

ステップ 7：ディスカッションへの昇格（スコア 80 以上のみ）

評価スコアが 80～100（エバーグリーン）の場合は、 ディスカッションへの昇格ワークフローを必ず実行してください。 スコアが 80 未満の場合は、このステップを完全にスキップしてください。

次の手順を順番に実行してください。

1. 完全な GraphQL ワークフローについて、modules/discussion-promotion.md を読む
2. ユーザーに次のように伝える：「このエントリーはエバーグリーンとしての成熟度に達しました。GitHub Discussions に公開します。[Y/n]」
3. ユーザーが「n」と答えた場合は、ステップ 8（適用）に進む
4. モジュールに記載されている gh api graphql コマンドを実行し、「Knowledge」カテゴリにディスカッションを作成または更新する
5. ローカルのコーパスエントリーを discussion_url で更新する

• エントリーにすでに discussion_url フィールドがある場合は、新しいディスカッションを作成するのではなく、既存のディスカッションを更新してください
• gh を使用できない場合、または昇格に失敗した場合は、ユーザーに警告してステップ 8（適用）に進んでください

条件を満たすエントリーは、デフォルトで公開します。公開によって取り込みワークフローが妨げられることはありません。

評価フレームワーク

重要度の基準

基準	重み	質問
新規性	25%	新しいパターンや概念を紹介していますか？
適用可能性	30%	現在の作業に適用できますか？
持続性	20%	6 か月以上にわたって関連性を保ちますか？
関連性	15%	既存の複数の概念とつながっていますか？
信頼性	10%	情報源は信頼でき、論理的に構成されていますか？

スコアガイド

• 80～100：エバーグリーンな知識です。目立つ場所に保管し、すぐに適用してください
• 60～79：価値ある知見です。コーパスに保管し、適用を予定してください
• 40～59：有用な参考情報です。芽として保管し、後で見直してください
• 40 未満：優先度は低く、重要な引用のみ記録するか、スキップしてください

適用先の振り分け

ローカルコードベースへの適用

知識によって現在のプロジェクトが直接改善される場合に適用します。

• バグ修正のパターン
• パフォーマンスの最適化
• このコードベースのアーキテクチャ上の決定
• ツール／ライブラリの推奨

アクション：コードを更新し、コメントを追加し、ADR を作成します

メタインフラストラクチャへの適用

知識によってプラグインエコシステムが改善される場合に適用します。

• スキル設計のパターン
• エージェントの動作の改善
• ワークフローの最適化
• 学習／評価の手法（Franklin Protocol など）

アクション：スキルを更新し、モジュールを作成し、エージェントを強化します

振り分け判断ツリー

**Verification:** Run the command with `--help` flag to verify availability.
Is the knowledge...
├── About HOW we build things? → Meta-infrastructure
│   ├── Skill patterns → Update abstract/memory-palace skills
│   ├── Learning methods → Add to knowledge-corpus
│   └── Tool techniques → Create new skill module
│
└── About WHAT we're building? → Local codebase
    ├── Domain knowledge → Store in project docs
    ├── Implementation patterns → Update code/architecture
    └── Bug/issue solutions → Apply fix, document

検証： --help フラグを付けてコマンドを実行し、使用可能かどうかを確認してください。

保存先

知識の種類	保存先	形式
メタ学習のパターン	docs/knowledge-corpus/	完全なメモリーパレスエントリー
スキル設計の知見	skills/*/modules/	技法モジュール
ツール／ライブラリの知識	docs/references/	クイックリファレンス
一時的な知見	デジタルガーデンの芽	軽量なメモ

整理の大切さ（KonMari に着想）

「散らかった宮殿は、散らかった心を生みます。」

新しい知識によって古い知識が置き換えられることはよくありますが、時間は基準ではありません。 重要なのは、関連性と自分の志向との一致です。

主キュレーター

何を残すかは、ループに参加する人間が決めます。大がかりな整理の前に、次のことを確認してください。

1. どんな自分になろうとしていますか？ - 開発者としての志向
2. 今、何に心が躍りますか？ - 「そうすべき」ではなく、心からの熱意
3. 何を卒業しましたか？ - 意識的に手放した過去の関心

2 つの質問

知識の各項目について、両方の答えが「はい」である必要があります。

• 心が躍りますか？ - 義務感ではなく、心からの熱意
• 自分の志向に役立ちますか？ - これからなりたい自分と一致しているか

整理のアクション

判断結果	アクション
置き換える	古いものに感謝してアーカイブし、背景情報としてリンクする
矛盾する	両方を評価し、心が躍るほうを残す
もはや一致しない	感謝して手放す
補完する	双方向リンクを作成する

**「いつか必要になるかもしれない」**は、喜びではなく恐れです。手放しましょう。

限界価値フィルタリング（汚染防止）

「既存のコーパスでは教えられないことを教えられないなら、取り込まないでください。」

知識を保存する前に、コーパスの汚染を防ぐため、必ず限界価値フィルターを実行してください。

3 段階のフィルター

1. 重複チェック

• 完全一致 → 直ちに却下
• 80％以上重複 → 重複として却下
• 40～80％重複 → 差分を評価（ステップ 2）
• 40％未満 → 新規性が高い可能性があるため、保存に進む

2. 差分分析（部分的な重複がある場合のみ）

• 新しい洞察／パターン → 価値が高い（0.7～0.9）
• 表現が異なるだけ → 価値が低い（0.2～0.4）
• 例が増える → 限界的な価値（0.4～0.6）
• 既存の内容と矛盾する → 調査する（0.6～0.8）

3. 統合の判断

• 単独で保存：新しい内容で、大きな重複がない
• 統合：既存のエントリーを例や詳細で補強する
• 置き換え：古くなった知識に取って代わる
• スキップ：限界価値が不十分

フィルターの使用方法

from memory_palace.corpus import MarginalValueFilter

# Initialize filter with corpus and index directories
filter = MarginalValueFilter(
    corpus_dir="docs/knowledge-corpus", index_dir="docs/knowledge-corpus/indexes"
)

# Evaluate new content
redundancy, delta, integration = filter.evaluate_content(
    content=article_text,
    title="Structured Concurrency in Python",
    tags=["async", "concurrency", "python"],
)

# Get human-readable explanation
explanation = filter.explain_decision(redundancy, delta, integration)
print(explanation)

# Act on decision
if integration.decision == IntegrationDecision.SKIP:
    print(f"Skipping: {integration.rationale}")
elif integration.decision == IntegrationDecision.STANDALONE:
    # Store as new entry
    store_knowledge(content, title)
elif integration.decision == IntegrationDecision.MERGE:
    # Enhance existing entry
    enhance_entry(integration.target_entries[0], content)
elif integration.decision == IntegrationDecision.REPLACE:
    # Replace outdated entry
    replace_entry(integration.target_entries[0], content)

確認： --help フラグを付けてコマンドを実行し、利用可能であることを確認してください。

フィルター出力の例

**Verification:** Run the command with `--help` flag to verify availability.
=== Marginal Value Assessment ===

Redundancy: partial
Overlap: 65%
Matches: async-patterns, python-concurrency
  - Partial overlap (65%) with 2 entries

Delta Type: novel_insight
Value Score: 75%
Teaching Delta: Introduces 8 new concepts
Novel aspects:
  + New concepts: structured, taskgroup, context-manager
  + New topics: Error Propagation, Resource Cleanup

Decision: STANDALONE
Confidence: 80%
Rationale: Novel insights justify standalone: Introduces 8 new concepts

確認： --help フラグを付けてコマンドを実行し、利用可能であることを確認してください。

段階的な自律性との統合

限界価値フィルターは自律性のレベルを尊重します（計画のフェーズ 4 を参照）。

• レベル 0：すべての判断で人間の承認が必要
• レベル 1：既知の分野では、スコアが 85 以上なら自動承認
• レベル 2：既知の分野では、スコアが 70 以上なら自動承認
• レベル 3：スコアが 60 以上なら自動承認し、明らかなノイズは自動却下

現在の実装：レベル 0（すべて人間が関与）。

強化学習ベースの品質スコアリング

知識コーパスでは、実際の使用パターンに基づき、エントリーの品質を動的にスコアリングするために、強化学習のシグナルを使用します。

アンカー質問による明確性ゲート

使用シグナルでエントリーをスコアリングできるのは、保存後にどのように アクセスされたかに基づく場合です。そもそも役に立つほど明確でなかった 要約を、使用シグナルで見つけることはできません。エントリーを記述する前に、 MMPO のデュアルプローブ（arXiv:2605.30159）を、タスクの状態から知識の 価値に応用してゲートを設けます。

1. 価値プローブ：この知識によって何ができるようになりますか？話題のラベルではなく、可能になる具体的な機能や判断を挙げてください。
2. ギャッププローブ：この知識では何に答えられませんか？「さらなる調査が必要」のような一般論ではなく、範囲を限定した未解決の質問を列挙してください。

価値プローブ	ギャッププローブ	判断
具体的な用途を示している	範囲が限定された具体的なギャップがある	評価済みのスコアで保存
具体的な用途を示している	「すべて」／空欄	保存するが、ギャップが示されるまでは芽生え段階に上限を設定
曖昧（「役立つ背景知識」）	いずれでも	知識としては保存しない。重要な引用のみを記録するか、スキップ

このゲートは定性的なものであり、「重要度基準」のスコアを補完しますが、置き換える ものではありません。要約は適用可能性のスコアが高くても、何を可能にするのかを 示せなければ、価値プローブを通過できないことがあります。 memory-palace:memory-clarity-probe がインストールされている場合は、 デュアルプローブの評価を委任し、その Recommendation をゲートとして使用してください。

使用シグナル

シグナル	重み	説明
ACCESS	+0.1	エントリーにアクセスした／閲覧した
CITATION	+0.3	別の文脈でエントリーが引用された
POSITIVE_FEEDBACK	+0.5	ユーザーが役立ったと評価した
NEGATIVE_FEEDBACK	-0.3	ユーザーが役立たなかったと評価した
CORRECTION	+0.2	エントリーが修正／更新された
STALE_FLAG	-0.4	エントリーが古くなっている可能性があるとマークされた

品質の減衰モデル

知識エントリーは、検証されない限り時間の経過とともに劣化します。

成熟度	半減期	減衰曲線
芽生え	14 日	指数関数的
成長中	30 日	指数関数的
常緑	90 日	対数関数的

エントリーは減衰状態によって分類されます。

• 新鮮：品質の 70％超を維持
• 古い：品質の 40～70％を維持
• 危機的：品質の 20～40％を維持
• アーカイブ済み：品質の 20％未満を維持

ソース系譜の追跡

ソースの重要度に基づくハイブリッドな系譜追跡：

完全な系譜（重要なソース向け）：

• 完全なメタデータを含む主要ソース
• 派生チェーン（どのエントリーから派生したか）
• 変換履歴（要約、抽出など）
• 検証チェーン（誰がいつ検証したか）

簡易な系譜（標準的なソース向け）：

• ソースの種類と URL
• 取得日時

完全な系譜は、次のものに使用されます：

• 研究論文
• ドキュメント
• 重要度スコアが 0.7 以上のエントリー

ナレッジオーケストレーター

KnowledgeOrchestrator は、すべての品質システムを調整します：

from memory_palace.corpus import KnowledgeOrchestrator, UsageSignal

# Initialize orchestrator
orchestrator = KnowledgeOrchestrator(
    corpus_dir="docs/knowledge-corpus", index_dir="docs/knowledge-corpus/indexes"
)

# Record usage events
orchestrator.record_usage("entry-1", UsageSignal.ACCESS)
orchestrator.record_usage("entry-1", UsageSignal.POSITIVE_FEEDBACK)

# Assess entry quality
entry = {"id": "entry-1", "maturity": "growing"}
assessment = orchestrator.assess_entry(entry)
print(f"Quality: {assessment.overall_score:.0%}")
print(f"Status: {assessment.status}")
print(f"Recommendations: {assessment.recommendations}")

# Get maintenance queue
entries = [...]  # Your entry list
queue = orchestrator.get_maintenance_queue(entries)
for item in queue:
    print(f"{item.entry_id}: {item.status} - {item.recommendations}")

# Ingest new content with lineage
from memory_palace.corpus import SourceReference, SourceType

source = SourceReference(
    source_id="src-1",
    source_type=SourceType.DOCUMENTATION,
    url="https://docs.example.com/api",
    title="API Documentation",
)
entry_id, decision = orchestrator.ingest_with_lineage(
    content="# API Reference\n...", title="API Documentation", source=source
)

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

限界価値フィルターとの RL 統合

限界価値フィルターは、統合の判断に関する RL シグナルを出力します：

from memory_palace.corpus import MarginalValueFilter

filter = MarginalValueFilter(corpus_dir, index_dir)

# Evaluate with RL signal emission
redundancy, delta, integration, rl_signal = filter.evaluate_with_rl(
    content=article_text, title="New Article", tags=["python", "async"]
)

# RL signal contains:
# - signal_type: UsageSignal to emit
# - weight: Signal weight for scoring
# - action: What happened (new_entry_created, entry_enhanced, etc.)
# - decision: Integration decision made
# - confidence: Decision confidence
print(f"RL Signal: {rl_signal['action']} (weight: {rl_signal['weight']})")

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

ワークフローの例

ユーザーが共有：「構造化並行処理に関するこの記事を確認してください」

intake:
  source: "https://example.com/structured-concurrency"

# PHASE 3: Marginal Value Filter
marginal_value:
  redundancy:
    level: partial_overlap
    overlap_score: 0.65
    matching_entries: [async-patterns, python-concurrency]
  delta:
    type: novel_insight
    value_score: 0.75
    novel_aspects: [structured, taskgroup, context-manager]
    teaching_delta: "Introduces structured concurrency pattern"
  integration:
    decision: standalone
    confidence: 0.80
    rationale: "Novel insights justify standalone entry"

# Continue with evaluation if filter passes
evaluation:
  novelty: 75        # New pattern for error handling
  applicability: 90  # Directly relevant to async code
  durability: 85     # Core concept, won't age quickly
  connectivity: 70   # Links to error handling, async patterns
  authority: 80      # Well-known author, cited sources
  total: 82          # Evergreen, store and apply

routing:
  type: both
  local_application:
    - Refactor async error handling in current project
    - Add structured concurrency pattern to codebase
  meta_application:
    - Create module in relevant skill
    - Add to knowledge-corpus as reference

storage:
  location: docs/knowledge-corpus/structured-concurrency.md
  format: memory_palace_entry
  maturity: growing

pruning:
  displaces:
    - Old async error patterns (mark deprecated)
  complements:
    - Existing error handling module
    - Async patterns documentation

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

キュー処理

調査セッションと外部コンテンツは、docs/knowledge-corpus/queue/ のレビューキューに自動的に追加されます。

キューエントリーの処理

# List pending queue entries
ls -1t docs/knowledge-corpus/queue/*.yaml

# Review specific entry
cat docs/knowledge-corpus/queue/2025-12-31_topic.yaml

# Process approved entry
# 1. Create memory palace entry in docs/knowledge-corpus/
# 2. Update queue entry status to 'processed'
# 3. Archive or delete queue entry

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

キュー統合

research-queue-integration フックは、次の項目を自動的にキューに追加します：

• WebSearch の呼び出しが 3 回以上あるブレインストーミングセッション
• 実質的な調査結果を含む、調査重視のセッション
• キューエントリーの作成による手動追加

キューエントリーの形式：docs/knowledge-corpus/queue/README.md を参照してください。

キューステータスのワークフロー

**Verification:** Run the command with `--help` flag to verify availability.
pending_review → [Review] → approved/rejected
approved → [Create Entry] → processed
processed → [Archive] → queue/archive/

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

自動化

• uv run python scripts/intake_cli.py --candidate path/to/intake_candidate.json --auto-accept を実行します
• CLI は限界価値フィルターを実行し、palace エントリー（docs/knowledge-corpus/*.md）と開発者向け草稿（docs/developer-drafts/）を作成し、監査ログの行を docs/curation-log.md に追加します。
• テストやサンドボックスでは --output-root を使用し、メインのコーパスが変更されないようにしてください。
• キュー処理：--process-queue フラグを使用して、キューに追加されたエントリーを対話形式でレビューし、処理します。

詳細なリソース

• 評価ルーブリック：modules/evaluation-rubric.md を参照してください
• ストレージパターン：modules/storage-patterns.md を参照してください
• KonMari の片付け哲学：modules/konmari-tidying.md を参照してください
• 片付けワークフロー：modules/pruning-workflows.md を参照してください
• ディスカッションの昇格：エバーグリーンエントリー（スコア 80 以上）に対して、ステップ 7（PROMOTE）で呼び出されます。既定のアクションは公開です。ワークフローの全容については、modules/discussion-promotion.md を参照してください。

フック統合

Memory-palace フックは、ナレッジ取り込み処理が必要な可能性のあるコンテンツを自動的に検出します。

自動トリガー

フック	イベント	トリガーされるタイミング
url_detector	UserPromptSubmit	ユーザーメッセージに URL が含まれているとき
web_content_processor	PostToolUse (WebFetch/WebSearch)	Web コンテンツの取得後
local_doc_processor	PostToolUse (Read)	ナレッジパス内のファイルを読み込むとき
research_queue_integration	SessionEnd	WebSearch の呼び出しが 3 回以上ある調査セッション

フックシグナル

フックがナレッジコンテンツの候補を検出すると、コンテキストメッセージを追加します：

**Verification:** Run `pytest -v` to verify tests pass.
Memory Palace: New web content fetched from {url}.
Consider running knowledge-intake to evaluate and store if valuable.

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

**Verification:** Run the command with `--help` flag to verify availability.
Memory Palace: Reading local knowledge doc '{path}'.
This path is configured for knowledge tracking.
Consider running knowledge-intake if this contains valuable reference material.

検証： --help フラグを付けてコマンドを実行し、利用可能かどうかを確認してください。

重複排除

フックは memory-palace-index.yaml を確認し、重複した処理を回避します：

• 既知の URL：「コンテンツはすでにインデックス化されています」—再評価をスキップします
• 変更されたコンテンツ：「コンテンツが変更されています」—更新を提案します
• 新しいコンテンツ：完全な評価を推奨します

安全性チェック

取り込みを通知する前に、フックはコンテンツを検証します：

• サイズ制限（既定値は 500KB）
• シークレットの検出（API キー、認証情報）
• データ爆弾の防止（繰り返し、Unicode 爆弾）
• プロンプトインジェクションのサニタイズ

インデックススキーマの整合性

重複排除インデックスには、このスキルの評価に合わせたフィールドが保存されます。

entries:
  "https://example.com/article":
    content_hash: "xxh:abc123..."
    stored_at: "docs/knowledge-corpus/article.md"
    importance_score: 82           # From evaluation framework, in [0, 100]
    maturity: "growing"            # seedling, growing, evergreen
    routing_type: "both"           # local, meta, both
    last_updated: "2025-12-06T..."

検証： --help フラグを付けてコマンドを実行し、利用可能であることを確認します。

統合

• memory-palace-architect - 保存された知識を空間的に構造化します
• digital-garden-cultivator - 知識のライフサイクルを管理します
• knowledge-locator - 保存された知識を検索して取得します
• skills-eval（抽象）- メタインフラストラクチャの更新を評価します
• memory-clarity-probe - 上記の明確さチェックのためのデュアルプローブゲート

完了条件

• 2xx 以外のフェッチ結果は破棄され、保存されません。HTTP 404/429 の本文からインデックスエントリーが作成されないこと（web_research_handler により強制）
• 保存されたすべてのエントリーがアンカー質問による明確さゲートを通過していること。価値プローブに、その知識によって可能になる具体的な機能が示されていること
• 各保存エントリーに [0, 100] の範囲の importance_score と、Application Routing ツリーによるルーティング判断があること
• スコアが 40 未満のエントリーは、引用として取得するかスキップし、完全なナレッジノートとして保存しないこと
• 取り込み後、インデックスをローダーで読み込み、元の状態に戻せること