concept-synthesis

concept-synthesis — 生のスタブから知的マップへ

規約： バックリンクの適用と引用の忠実性の要件については、conventions/quality.md を参照してください。

規約： _brain-filing-rules.md を参照してください。主要対象ルールに従い、出力ファイルを concepts/ の下に配置します。

解決する課題

多くの取り込みパイプライン（signal-detector、idea-ingest、voice-note-ingest）は、言及されたアイデアごとにコンセプトページを作成します。これを数か月続けると、次のような状態になります。

• スタブページが何千件もでき、その多くは重複またはほぼ重複しています
• 複数のコンセプトページにわたり、同じソースを繰り返すタイムライン項目が作成されます
• 統合がなく、「ユーザーがこの日に X について言及した」という記録だけが残ります
• ティアの割り当てがなく、すべてが平坦なままです
• クラスタリングがなく、関連するアイデアがリンクされません

このスキルは、こうした生の素材を、精選された知的マップへと変換します。

アーキテクチャ

Phase 1: Dedup + merge (deterministic)
  N stubs → ~N/4 canonical concepts
    ├── Jaccard dedup (word-overlap on titles + first-paragraph)
    ├── Substring dedup ("founder mode" vs "founder mode vs manager mode")
    ├── Semantic dedup (LLM: "are these the same idea?")
    └── Merge timelines + aliases from duplicates into the canonical page

Phase 2: Score + tier (deterministic + heuristic)
  Each canonical concept → scored and tiered
    ├── Frequency: distinct sources referencing this concept
    ├── Timespan: first mention → last mention in days
    ├── Breadth: distinct months it appears in
    ├── Engagement: avg engagement on concept-bearing sources (if available)
    └── Tier: T1 Canon | T2 Developing | T3 Speculative | T4 Riff

Phase 3: Synthesize (LLM, T1+T2 only)
  T1 + T2 concepts → rich synthesis
    ├── Evolution narrative: how the idea sharpened over time
    ├── Best articulation: highest-engagement or most precise quote
    ├── Related concepts: cross-links to other concepts
    ├── Context: what was happening when this idea emerged / evolved
    └── Counter-positions: what this idea argues against

Phase 4: Cluster + map (LLM)
  All tiered concepts → intellectual clusters
    ├── Group related concepts into domains (auto-named via LLM)
    ├── Generate cluster summary pages
    ├── Build a master concepts/README.md with the full map
    └── Identify idea genealogies (concept A → evolved into concept B)

Phase 5: Curation cull (rubric + reversible merge)
  Each concept → hard verdict: ELITE | KEEP | MERGE/REWRITE | DELETE
    ├── 6-axis rubric (substance 2x, packaging 1x) + minimum substance gate
    ├── Grounding labels (VERIFIED / OPINION / NEEDS_SOURCE / UNSAFE)
    ├── Cluster budgets + reputational-risk gate
    ├── Merge-with-backlinks into cluster canonicals (fully reversible)
    └── merge_count / independent_sources → emergent tier promotion

呼び出し

このスキルは Markdown 形式のエージェント指示です。エージェントは gbrain の既存の操作と LLM の処理を使用します。

# 1. List all concept pages
gbrain query "type:concept" --limit 10000 --json

# 2. Phase 1 dedup — agent applies Jaccard + substring locally,
#    then LLM passes to identify semantic duplicates.

# 3. Phase 2 tier — agent scores each canonical concept based on
#    frequency / timespan / breadth and writes tier into frontmatter.

# 4. Phase 3 synthesis — for each T1/T2, agent reads the timeline
#    + associated source pages and writes a synthesis section
#    onto the concept page via put_page.

# 5. Phase 4 clustering — agent reads the tiered concept list
#    and writes concepts/README.md with the full intellectual map.

出力：コンセプトページの形式（統合後）

T1 Canon — 完全な統合

---
title: "concept name"
type: concept
tier: 1
tier_label: "Canon"
mention_count: 18
distinct_months: 8
first_mention: "YYYY-MM-DD"
last_mention: "YYYY-MM-DD"
composite_score: 78.4
aliases: ["alternate phrasing 1", "alternate phrasing 2"]
related: ["sibling-concept-1", "sibling-concept-2"]
---

# concept name

**Tier 1 — Canon** | 18 mentions across 8 months

## Synthesis

[2-4 paragraph narrative tracing how the idea evolved, what it means in
the user's worldview, why it matters. Third-person analytical voice.]

## Best Articulation

> "Verbatim quote from a source — the most precise or highest-engagement
> expression of this idea." — [Date](source-url)

## Evolution

| Period | Expression | Signal |
|--------|-----------|--------|
| YYYY-MM | "First articulation" | First use — aspiration frame |
| YYYY-MM | "Sharpening" | Anti-pattern emerges |
| YYYY-MM | "Peak form" | Cleanest expression |

## Related Concepts
- [sibling concept](sibling-concept.md) — relationship description
- [sibling concept](sibling-concept.md) — relationship description

## Timeline
[Full timeline with deduped entries, quotes, source links]

T3 / T4 — スタブのみ（LLM による統合なし）

---
title: "concept name"
type: concept
tier: 4
tier_label: "Riff"
mention_count: 1
---

# concept name

**Tier 4 — Riff** | 1 mention

> "Quote from the source" — [Date](URL)

出力：concepts/README.md のクラスタマップ

# Intellectual Universe

## Canon (T1) — N concepts
The permanent intellectual fingerprint. Ideas that recur across years.

### [Cluster Name]
- [concept-slug](concept-slug.md) — one-line characterization
- ...

### [Other Cluster]
- ...

## Developing (T2) — N concepts
Sharpening. Might become canon.

## Speculative (T3) — N concepts
Testing in public.

## Stats
- Total concepts: N
- T1 Canon: N
- T2 Developing: N
- T3 Speculative: N
- T4 Riff: N
- Earliest source: YYYY-MM-DD
- Latest source: YYYY-MM-DD

フェーズ 5：精選のための整理 — 維持／削除／統合の基準

フェーズ 1〜4 では上位への統合のみを行い、何も削除しません。数か月後には、空疎なスタブが、実際に価値を積み重ねていくコンセプトを薄めるコーパスが残ります。フェーズ 5 は整理の段階です。コンセプトごとに明確な判定を行い、定期的または必要に応じて実行します。破壊的な手順はすべて元に戻せます。

規約： conventions/test-before-bulk.md を参照してください。 — まず 3〜5 個のクラスタを整理し、実際の出力を確認してから、全体に対して実行します。

中心となる問い

2 年後、ユーザーがこのコンセプトを何の予備知識もなく読み返したとき、考えが研ぎ澄まされたり、新しい発想の種になったりするでしょうか。それとも、内容の薄いものとして読み飛ばすでしょうか。

読み飛ばされるなら、削除します。

6 つの評価軸（各 1〜5 点）

内容に関する 3 つの軸は 2 倍、パッケージング／適合性に関する 3 つの軸は 1 倍の重みです。内容がコンセプトを支え、パッケージングがその存在価値を高めます。

内容（重み 2 倍）：

軸	1	3	5
洞察と緊張感 — メカニズム、意外性のある因果関係、反転、隠れたコストなど、実質的な知的負荷を担っている	陳腐な一般論（「スタートアップは大変」）	特定の切り口を持つ、よく知られたアイデア	再利用できる、名付けられたメカニズム
独創性と意外性 — 誰でも書ける決まり文句ではなく、予想を覆す新鮮な捉え方がある	格言めいた決まり文句（「規律はモチベーションに勝る」）	ユーザー独自の視点を通した既知のアイデア	新たに生み出された、応用可能な枠組みと感じられる
具体性と完全性 — 具体的な詳細を伴う、自己完結した主張／メカニズム／区別であり、欠けた文脈を必要とする断片ではない	曖昧、または途中で途切れている	完全だが一般的	具体的で、根拠があり、それ単独で完全に成立している

パッケージングと適合性（重み 1 倍）：

軸	1	3	5
勢いと機知 — 鋭い転換、凝縮、印象に残る一節など、言葉に力がある	平板／教科書的	明快	引用したくなる切れ味がある
本人らしさ — ユーザーらしく聞こえる、または記録されたユーザーの世界観につながっている	誰が書いてもおかしくない	ユーザーの視点と相性がよい	まぎれもなくユーザーならではの特徴がある
力強さと明瞭さ — そのまま使える材料（エッセイの一節、講演の一言、会議の枠組み）であると同時に、ユーザーの実像を伝える	内容のない豆知識	工夫すれば使える	そのまま使えて、ユーザーへの理解も深まる

スコアから判定へ

加重スコア = （洞察 + 独自性 + 具体性）× 2 + （熱量 + 代表性 + 力強さ）× 1。最大 45。パーセンテージで表します。

加重スコア％	判定	併せて満たす必要がある条件
≥85%	エリート — 維持し、再利用用にフラグを付ける	どの軸も 3 未満でないこと。5 が 2 つ以上あり、そのうち少なくとも 1 つは内容軸であること
75-84%	維持	（洞察 ≥4 または 独自性 ≥4）かつ 具体性 ≥3 かつ（代表性 ≥3 または 力強さ ≥4）
55-74%	統合／書き直し、または条件付きで維持	アイデアは優れているが、本文に問題がある場合は、クラスターの基準となる概念に統合するか、単独で成立するように書き直します。出所が珍しい場合や、網羅性の不足を補う場合に限り、そのまま維持します。それ以外は削除します。
<55%	削除	—

内容の最低基準（スコア％より優先）： 洞察が 3 未満、または独自性が 3 未満の概念は、維持またはエリートにできません。アイデアが空疎でも、文体で基準をすり抜けることはできません。

「統合／書き直し」は実質的な第 3 の判定であり、判断を避けるための選択肢ではありません。多くの断片には、弱い本文に閉じ込められた生きたアイデアがあります。それらをクラスターの基準となる概念に統合するか、単独で成立するように書き直します。洞察が 3 以上でも、具体性や熱量がスコアを下げている場合に使います。

即時削除の条件（いずれか 1 つでも該当すれば、スコアにかかわらず削除）

• ありきたりな格言の言い換え — 正しいものの、グリーティングカードに書かれていてもおかしくない程度で、何も伝えていません。決まり文句であり、仕組みの説明もありません。
• 断片 — 利用できない文脈が必要で、それだけでは意味が通じません（出所が珍しい場合を除きます。その場合でも、理解可能で役に立つ場合に限ります）。
• 抽出の破損 — 書き起こしの乱れ、文の途中での切断、支離滅裂な内容、または概念を装ったチャンクの見出し。
• 目的から外れた雑学 — 正確ではあっても、ユーザーが作るもの、信じること、または活用できることと無関係です。
• クラスター内の重複 — 以下の実務的な重複テストを満たしません。
• 裏付けのない事実の主張 — 事実、歴史、因果関係に関する主張が誤っている、または出典がなく、事実として述べられています（グラウンディングラベルを参照）。表現を弱めるか、削除してください。

グラウンディングラベル（事実に関する概念のみ）— 減点するだけでなく、ラベルを付ける

事実、歴史、科学、または因果関係に関する主張はすべて真偽を確認し、grounding: フロントマターラベルを付けます。

• 検証済み — 正確で、出典があります。維持して展開できます。
• 意見 — ユーザー自身の見解や主張として明確に示されています。問題ありません。
• 出典が必要 — もっともらしいものの、事実として述べるには出典がありません。主張や意見として言い換える場合に限り維持できます。
• 危険 — 誤り、または印象的ではあるものの事実ではありません。削除するか、表現を弱めてください。

確信に満ちた誤情報は保存しないでください。展開すると、ユーザーへの理解を深めるどころか、誤解を招きます。引用については conventions/quality.md に従ってください。

評判リスクの判定基準

印象的であっても、ユーザーを誤って伝えるおそれがある概念——残酷な人物、人を見下す人物、または本人が支持していない立場を取る人物に見せるもの——は、武器ではなく負債です。熱量が高くても、書き直しまたは削除の対象としてフラグを付けてください。力強さとは、反発を招かずに使えることです。

クラスターの上限（「数が増えると陳腐になる」問題）

多くの概念が 1 つのソースに由来する場合や、同じアイデアを共有する場合は、それぞれを個別に評価するのではなく、全体を評価してください。意味上のクラスターごとの標準的な上限は次のとおりです。

• 基準となる概念を 1 つ（仕組みを最も鋭く表現したもの）— 必ず残します。
• さらに 1～2 個は、各概念が独自の仕組み、具体例、異なる感情的トーン、新しい対象読者、またはユーザー独自の特徴的な言い回しを加える場合に限ります。
• 3 個を超える場合は、進行中のプロジェクトに関連する場合に限ります。

クラスター内のそれ以外の概念は、統合（推奨。以下を参照）または削除します。1 つのテーマについて、ほぼ同じ断片が 40 個ある場合は、仕組みを示す基準となる概念を 1 つ、優れた一文があればそれを 1 つ残し、残りは統合します。

実務的な重複テスト

「重複率」を目視で判断しないでください。候補をクラスター内の最良の既存概念と比較し、次のように問いかけてください。新しい仕組み、例、感情的トーン、対象読者、またはユーザー固有の言い回しが加わっていますか？ いいえの場合は、統合（要点を保ったまま取り込む）または削除します。はいの場合は、加わった要素こそが維持する理由です。

厳格な KEEP のオーバーライド（低スコアを救済。ただし下限あり）

各オーバーライドは、その概念が理解可能で、役立つ可能性がある場合にのみ適用されます。

• 一人称の語り口 — ユーザー本人にしか言えないことを捉えています。語り口は洗練度より優先されますが、一貫性を損なうほどではありません。
• 進行中のプロジェクトに不可欠 — 既知の論点や進行中の作業に直接つながります。
• 希少な来歴 — 再現できない実際の発言や出来事（会議やユーザー自身のメモなど）であり、かつ意味を読み取れるものです。「AI の件について素晴らしい指摘」のように内容のないものは該当しません。

バックリンク付きで統合（元に戻せる — 何も失われません）

重複クラスターの場合、削除の方向を逆にします。末尾の項目を削除せず、正規の先頭項目に統合し、統合台帳を重要度の指標にします。あるアイデアが独立して N 回再導出されたなら、それは冗長さではありません。コーパスが、N 種類の異なる文脈で「これは重要だ」と示しているのです。重複を削除するとそのシグナルが失われますが、統合すれば捉えられます。

統合するたびに、正規の項目にフロントマターのフィールドを 3 つ、本文セクションを 1 つ追加します。

• merge_count（int） — 吸収したページの生の件数。同一ソースからの再抽出も含みます。
• independent_sources（int） — クラスターが参照した異なるソースの数です。これが真の重要度指標です。同じソースが繰り返し再抽出されると生の merge_count は膨らみますが、independent_sources ならそれを補正できます。
• backlinks（{source, angle, date} のリスト） — 吸収した各ページのソースと、そのページが持ち込んだ具体的な切り口です。あらゆる捉え方を残し、トップレベルのページとして分けておくのをやめるだけです。
• ## Facets（本文） — 冒頭に正規の仕組みを記載し、その後、吸収したページごとに「{source} では、{angle} のように見られています」という短い行を 1 つ記載します。概念は重複ではなく、複数の切り口を持つようになります。

統合品質ゲート（不完全な統合は却下）: 統合を記録するのは、（a）## Facets セクションに吸収した各ページについて 1 行ずつ（ソースと具体的な切り口）記載され、（b）すべての backlinks エントリーにソース、切り口、日付が記載されている場合のみです。Facet が空、または情報が欠けているエントリーがあれば、統合を却下し、クラスターに手動レビューのフラグを立てます。不完全な統合は認めません。

明確な区別を守るガードは助言ではなく、厳格な拒否基準です。 重複に見える 2 つの概念も、LLM の判定者が同じ仕組みを述べていると明確に確認しない限り、統合しません。デフォルトは統合しないことです。判定者が統合を認める必要があり、その賛否と理由をクラスターごとに記録します。仕組み、例、文体が異なる場合は、別々の正規項目にします。類似性が候補を提案し、判断が結論を下します。

統合候補の見つけ方 — 数値のしきい値ではなく定性的な範囲で判断します。 類似度のしきい値をハードコードしないでください。gbrain search が返すのは RRF で融合されたハイブリッドスコアであり、生のコサイン類似度ではありません。また、コーパスや検索モードが変われば、固定した数値はすぐに役に立たなくなります。定性的に作業してください。各概念のタイトルと最初の段落で検索し、別の概念が検索結果の上位で互いに現れ、ほかの結果と目に見えるスコア差がある場合、2 つの概念を統合候補として扱います。語彙は共通していても仕組みが異なる概念は、リストの中ほどに現れます。そこがまさに、明確な区別を守るガードの真価が発揮される範囲です。一括処理を行う前に、独自のコーパス分布で調整してください。

統合の仕組み（段階的で、完全に元に戻せます）

# 0. Inventory the stratum being culled
gbrain query "type:concept" --limit 10000 --json

# 1. Probe for merge candidates (mutual top-of-list hits)
gbrain search "concept title + first paragraph" --limit 10

# 2. Archive the absorbed page verbatim under _merged/ BEFORE touching it
#    (add merged_into: <canonical-slug> to its frontmatter). The _merged/
#    tree is the undo button.
gbrain get concepts/absorbed-stub
gbrain put concepts/_merged/cluster-name/absorbed-stub

# 3. Grow the canonical head: merge_count, independent_sources,
#    backlinks, and the ## Facets section
gbrain put concepts/canonical-slug

# 4. Soft-delete the absorbed original (restorable until purge)
gbrain delete concepts/absorbed-stub

# Undo paths: gbrain restore <slug> (within the purge window),
# the _merged/ copy (survives purge), and per-page version history:
gbrain history concepts/canonical-slug
gbrain revert concepts/canonical-slug <version_id>

段階的にコミットしてください。整理中に完全削除することはありません。_merged/ ツリー、ソフト削除、ページ履歴によって、すべての手順を元に戻せます。

統合台帳 → 創発的なティア昇格

independent_sources を Phase 2 の Frequency 軸に取り込みます。正規の概念の independent_sources がコーパスのヒストグラムに自然に現れる間隔を超えたら、ティア昇格の候補になります（T4→T3、T3→T2、T2→T1 のレビュー）。丸い数値をハードコードせず、分布を確認してください。サイズ上限は設けません。統合を吸収し続ける概念は、太っていくべきです。ティアの境界は人為的に引くのではなく、創発的なものになります。つまり、繰り返し現れるアイデアがそのティアに値することを、コーパスが示すのです。

品質ゲート

重複排除の品質

• 2つの概念ページが「同じアイデアを別の言葉で表現しただけ」になってはいけません。
• 検索に使えるよう、エイリアスをフロントマターに残してください。
• gbrain query "type:concept" を実行し、件数の減少を抜き取り確認してください。

ティアの品質

• T1 は「そう、これは私が繰り返し使っているフレームワークの1つだ」と感じられるものにします。見分けやすく、繰り返し現れ、明確である必要があります。
• T2 は「今取り組んでいて、だんだん明確になってきている」と感じられるものにします。
• 期間が4か月未満、または言及数が6回未満の概念をT1にしてはいけません。
• 期間が3か月を超える概念をT4にしてはいけません。

統合の品質

• 単なる繰り返しではなく、変化の過程を捉えます。
• 言い換えではなく、原文そのままの引用を使います。
• 関連する概念へのリンクを追加します（wikiリンクではなく、Markdownリンク）。
• 出典や日付を捏造してはいけません。

削除の品質

• クラスター内で唯一のメカニズムに関する記述を含む概念は削除してはいけません。正規版はすべての削除後も残します。
• すべての統合で、統合品質ゲートを通過させます。## Facets が記入済みで、backlinks エントリがすべて揃っている必要があります。中途半端な統合は認められません。
• クラスターごとに識別性ガードの判定を記録します。統合内容を書き込む前に、判定者が明確に承認している必要があります。
• UNSAFE のラベルが付いた主張を、事実として残してはいけません。
• 吸収したすべてのページについて、元のページをソフト削除する前に、原文そのままのコピーを _merged/ に保存します。

Cron との連携

これは負荷の高い作業です。すべてのシグナルに対して実行するのではなく、定期的に実行します。

• 大規模な取り込みバッチが完了した後（signal-detector のバースト、アーカイブクローラーの実行など）。
• 新たに昇格したT1/T2概念を段階的に統合する、週次の cron。
• コーパスが大きく変化した場合に、完全な再統合を手動で実行します。
• Phase 5 の削除は統合より頻度を下げ、月次、または大規模な取り込みによってスタブ数が目に見えて増えた後に実施します。必ず、最初に一括処理前のテストを行ってください。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または notice ブロックが発生した場合は、エージェント運用者プロトコルに従ってください。このスキル固有の対応は次のとおりです。

• LLM 判定または統合処理がコスト上限で停止した場合（cost_cap_exceeded、または resume_command を伴う終了コード 11）、完了した内容を報告します。表示されたコマンドで再開できるのは、ユーザーが合意した予算の範囲内に限ります。
• ユーザーが上限を設定している状態で no_pricing が発生した場合は、ユーザーに伝え、モデルのトークンあたりの料金を調べます。そのうえでユーザーの合意を得てから、brain ホストの運用者に gbrain pricing set <model> --input <usd-per-1M> --output <usd-per-1M> で登録するよう依頼してください。
• 概念ページの書き換え時に revision_conflict が発生した場合は、再読み込みして統合します。再読み込みしていないページを統合してはいけません。

アンチパターン

• ❌ T3/T4 に対して統合を実行すること。明確化する可能性のないアイデアに API 予算を浪費します。
• ❌ 引用や日付を捏造すること。タイムラインは既存の brain ページと照合して検証できる必要があります。
• ❌「Various Topics」のような汎用的なクラスター名を使うこと。クラスターに名前を付けられないなら、そのクラスターは実在しません。
• ❌ 新しいソース資料がないのに、すでに統合済みのT1を再統合すること。冪等性を尊重してください。
• ❌ 統合候補に数値の類似度しきい値をハードコードすること。検索スコアはコーパスとモードによって相対的に変わります。定性的な区分を使い、識別性ガードに判断を委ねてください。
• ❌ 類似性だけを根拠に統合すること。語彙の共有はメカニズムの共有を意味しません。識別性ガードは参考意見ではなく、拒否権を持ちます。
• ❌ 重複する概念を上位の概念に統合せず、削除すること。削除すると、ティア昇格の判断に使う頻度シグナルが失われます。
• ❌ 表現がきれいだからという理由で、中身のない概念を残すこと。最低限の内容に関するゲートは、まさにこれを防ぐためにあります。
• ❌ 削除時に完全削除すること。_merged/ にアーカイブしてからソフト削除し、すべての取り消し手段を残してください。
• ❌ 3〜5個のクラスターを抜き取り確認する前に、一括削除すること（conventions/test-before-bulk.md）。

関連スキル

• skills/signal-detector/SKILL.md — テキストチャネルから概念の生スタブを作成します
• skills/voice-note-ingest/SKILL.md — 音声チャネルについて同様の処理を行います
• skills/idea-ingest/SKILL.md — リンクや記事について同様の処理を行います

契約

このスキルでは、次のことを保証します。

• ルーティングがフロントマターの正規トリガーに一致します。
• （該当する場合）writes_to: に記載されたディレクトリ配下に出力を書き込みます。
• 参照されている規約（quality.md、brain-first.md、_brain-filing-rules.md）に従います。
• プライバシー契約を維持します。実名、フォーク固有のファイルシステムパスを示すリテラル、上流フォークへの言及は含めません。

動作契約の全文は上記の本文セクションに記載されています。このセクションは適合性テスト用に設けられています。

出力形式

スキルの出力形式は、本文セクション内に記載されています（「Output」、「Brain page format」または同等の項目を参照）。ここにある見出しは、適合性テスト（test/skills-conformance.test.ts）用のものです。