wiki-crystallize

Wiki Crystallize

一時的な会話を、永続的で構造化された Wiki ナレッジに凝縮します。

---

設定の検出

すべての呼び出しはここから始めます。 Wiki のルートは、wiki-config.md があるディレクトリです。スキルは実行時にこれを特定します。このスキルが書き込むページは、wiki-schema.md の構造に従います。両方のファイルが存在する必要があります。

1. スコープを特定する：ファイルシステムのスコープルート、つまりファイルシステムツールがアクセスできる最上位ディレクトリを特定します。

2. スコープを確認する — 必ず停止すること：スコープがドライブのルート（C:\、D:\、/）、OS のルート、またはユーザーホーム（C:\Users\X、/home/X、/Users/X）の場合は、直ちに停止してください。検索したり、wiki-config.md の場所を特定しようとしたりしてはいけません。 手順 6 に進んでください。

3. <available_skills> を検索して wiki-config を確認します。 利用可能かどうかを記録します。これは以下の推奨事項に影響します。バンドルされている references/setup-help.md も利用可能です。ユーザーが案内を必要としている場合や、行き詰まった場合は読み込んでください。

4. wiki-config.md を見つけて読み込みます：再帰的に検索します（最初に一致したものを使用し、最大 5 階層まで）。見つかった場合は読み込みます（blacklist、index_excludes、ingested_folder、ingested_subdirs、log_format）。見つからない場合は手順 6 に進みます。

5. wiki-schema.md を見つけて読み込む — 必須確認：wiki-config.md と同じディレクトリに wiki-schema.md が存在し、YAML として解析できることを確認します。明確な判定（存在／欠落／形式不正）が得られるまで、以下のワークフローに進んではいけません。その後：

   • 存在し、問題なく解析できる場合 → スキーマ（mandatory_fields、conditional_fields、enums）を読み込み、ワークフローに進みます。

   • 欠落している場合 → 停止します。先に進んだり、デプロイしたりしてはいけません。応答は、手順 3 で確認した <available_skills> に wiki-config が含まれているかどうかによって異なります：

     • wiki-config が利用可能な場合： 次の形式で正確に出力します — "Your wiki is missing wiki-schema.md. Run /wiki-config to deploy it and complete setup. I'll wait for that to be done before proceeding." これでターンを終了します。バンドル版のデプロイを提案したり、別の方法を提示したりしてはいけません。wiki-config が利用可能な場合は、ガイド付きフローを利用するのが適切です。

     • wiki-config が利用できない場合： バンドル版による代替案を提示します — "Your wiki is missing wiki-schema.md and the wiki-config skill is not installed. I can deploy a default from my bundled reference, but I'd recommend installing wiki-config for the guided setup. Deploy bundled default?" 明示的な確認を待ちます。了承された場合は、references/wiki-schema.md をデプロイします。

   • 形式不正の場合 → 停止します。同じ構成で対応します：

     • wiki-config が利用可能な場合： "wiki-schema.md is malformed. Run /wiki-config - it has a guided repair flow that preserves any customizations you've made. I'll wait." これでターンを終了します。修復を試みたり、バンドル版で上書きしたりしてはいけません。

     • wiki-config が利用できない場合： 手動で修復する方法について、references/setup-help.md を案内します。ユーザーが明示的にリセットを指示した場合（自動的な代替手段としてではなく）は、カスタマイズ内容が上書きされることを警告したうえで、明示的な了承を得てからデフォルトをデプロイします。

   手順 4 で wiki-config.md 自体が形式不正と判明した場合も、同じ 2 つの分岐が適用されます。wiki-config が利用可能な場合は、停止して /wiki-config を推奨し、ターンを終了します。利用できない場合は、setup-help.md に沿って手動で修復します。

6. 設定が見つからない場合：ユーザーに Wiki のルートパスを尋ね、その場所を検索します（範囲を限定し、最大 5 階層まで）。それでも見つからない場合は、Wiki がまだありません。上記の「欠落している場合」の分岐に従います（/wiki-config を推奨し、利用できない場合はバンドル版のデプロイを提案します）。

---

必要な機能

このスキルには、ファイルシステムの読み書きアクセスが必要です。現在の環境（Web、モバイル）で利用できない場合は、ユーザーが手動で保存できる成果物として Wiki ページを作成することを提案します。

目的

Crystallize は、チャットの中から長く役立つ情報（決定事項、発見、パターン、未解決の質問）を抽出し、構造化された Wiki ページにまとめます。これにより、将来のセッションでスレッドを読み直すよりもすばやく状況を把握できます。

積極的に使ってください。意味のあることが起きたら、いつでも使えます。長く続いたスレッドや、疲弊したスレッドだけに限りません。これはセッション管理の仕組みです。Wiki はチャットのサイクルをまたいで保持される記憶であり、チャット履歴は足場にすぎません。チャットを終了する前に Crystallize を実行してください。後片付けとして使うものではありません。

保持するもの： 決定事項、確立されたパターン、学んだ教訓、未解決の質問、現在の理解、重要な発見。 破棄するもの： 探索的なやり取り、行き詰まった案、作業手順に関するチャット、置き換えられた草稿。

レベル	使用するタイミング	終了時の方針
単一セッション	作業セッションの終了時。コンテキストにはまだ価値がある	終了ではなく、一時停止
トピックスレッド	複数のセッションにまたがってスレッドが長くなってきたとき	新しいスレッドの開始を推奨
チャット全体	スレッドを使い切ったとき、または明示的にアーカイブするとき	明確に終了

---

入力

次のいずれかを提示してください。

1. スレッドの要約（自分の言葉で）
2. 会話の書き起こしまたはエクスポート
3. 達成したことと決定したことの説明

いずれも提示されていない場合は、続行する前に、この Crystallize で何を記録すべきかユーザーに説明を求めてください。

---

ワークフロー

Config Discovery によって wiki-config.md と wiki-schema.md はすでにコンテキストに読み込まれています。再読込せず、両方が利用可能であるものとして、ここから進めてください。

ステップ 1 - Overview.md を読む

Overview.md を読み、現在の知識の状態を把握してください。Crystallize は Wiki に情報を追加するものであり、既存の内容を重複させるものではありません。

ステップ 2 - 入力を分析する

長く役立つ知識（決定事項、発見、パターン、未解決の質問、現時点で最も妥当な理解）を特定し、会話の足場となる内容（探索的なやり取り、置き換えられた草稿、作業手順、すでに反映された修正）は破棄してください。

ステップ 3 - この知識に適した既存の保存先を探す

候補を調べる前に、このトピックが既存のドメインに属するかどうかを確認してください。そのドメインの Domain Home がある場合は、まずそこを対象とします。別の候補を探すのではなく、適合するか確認するためにスキャンしてください。新しいファイルを作るより、ハブの更新を優先してください。

index.md を読み、次の項目を探してください。

• 対象範囲をカバーする Domain Home（最初に確認）
• トピックと一致するタイトルのページ
• この領域の「Current State」または要約ページ

強く一致するページが見つかった場合： そのページを更新します。ステップ 4a に進んでください。

候補が複数ある、または不明確な場合： ユーザーに「適切な保存先と思われるページが見つかりました：[list]。いずれかを更新しますか、それとも新規作成しますか？」と尋ねてください。回答を待ちます。

適合する既存ページがない場合： 内容が明らかに独立している場合を除き、新規作成の前にユーザーに確認してください。

重要なルール： 迷った場合は、新規作成よりハブの更新を優先してください。新しいページを作るとグラフが分断され、情報量の豊富なハブを更新すれば、そこに蓄積される価値が高まります。

Step 4a - 既存のページを更新する

対象ページの現在の内容をすべて読み込みます。結晶化された知識を統合します。

• 新しい決定事項、調査結果、未解決の質問を適切なセクションに追加します

• 古くなったセクションを更新します

• すでに記載されている内容を重複させず、統合してまとめます

• description: の書き換え - ページのセクション構成が変わった場合、対象範囲が変わった場合、または大幅な新しい内容が追加された場合は、description: フィールドを書き換えます。既存セクションへの追加が段階的なものであれば、description: は変更しません。判断はエージェントに委ねられます。

• frontmatter の version:、changes:、updated: フィールドを更新します。date: は作成日なので変更しません。crystallize_count: をインクリメントします。現在の値を読み取り、1を加えます。フィールドがない場合は、1を設定します。

• Page_type の確認： ページの frontmatter に page_type があることと、その値が現在も適切であることを確認します。ない場合は、ページの内容と構成から推定し、設定する前にユーザーに確認します。存在するものの、ページが現在のタイプを超えて発展しているように見える場合（例：knowledge ページがドメインハブとして機能するようになった場合、または knowledge ページが比較調査へと発展した場合）は、タイプの昇格を提案します。「このページは <type> として設定されていますが、現在は <better-type> の方が適切に見えます。ここで page_type を更新しますか？」 自動で昇格してはいけません。必ず確認してください。

Step 4b - 新しいページを作成する

page_type を決定し、テンプレートを読み込む：

スキーマの enum から page_type を選択します。一般的な結晶化の出力は、knowledge（単一トピックの調査結果）、domain-home（新たに構築するドメインハブ）、overview（Vault 全体の統合）、survey（複数項目にまたがる比較調査）です。タイプが明確でない場合は、作業を進める前にユーザーに確認します。スキーマの enum に照らして検証します（すでにコンテキストにあります）。

wiki-config.md から templates_folder を読み込みます（すでにコンテキストにあります）。値がある場合は、<wiki_root>/<templates_folder>/<page_type>.md の読み込みを試みます。見つかった場合は、これを本文のひな形として使い、{{TITLE}}、{{DATE}}、{{PAGE_TYPE}}、{{DESCRIPTION}} を置き換えて、結晶化された内容で各セクションを埋めます。テンプレートファイルが見つからない場合は、次の1行を出力します。「<page_type> のテンプレートが見つかりません。デフォルトの構成を使用します。」 そのうえで、以下のハードコードされたテンプレートを使用します。設定ファイルに templates_folder がない場合は、黙って検索を省略し、以下のハードコードされたテンプレートを使用します。

フォールバックテンプレート（Vault 側のテンプレートが見つからない場合に使用）：

---
title: Topic - Current State
version: 1.0
date: YYYY-MM-DD
updated: YYYY-MM-DD
crystallize_count: 1
description: "~200 char synthesis of what this page covers"
changes: "Crystallized from [source chat / session description]"
---

# Topic - Current State

## What Was Established
[2-4 sentences: the core finding or current understanding]

## Key Decisions
[Decisions made, with brief rationale]

## Current Understanding
[The substantive content, structured as appropriate: prose, tables, lists]

## Open Questions
[What remains unresolved. Be specific.]

## Related Pages
[[Related Page 1]], [[Related Page 2]]

## Sources

| Title | Publisher | Date | Links |
|---|---|---|---|

index.md のフォルダー構成を使い、最も具体的な保存場所を選びます。ブラックリストに登録されたパス、raw/、archive/、Projects/ には配置しません。保存場所が明確でない場合は、ユーザーに確認します。

Step 5 - index.md を更新する（新しいページのみ）

Step 4b で新しいページを作成した場合は、index.md の適切なセクションにエントリーを追加します（1文、最大150文字）。Step 4a で既存のページを更新した場合は、index を変更する必要はありません。

Step 6 - 必要に応じて Overview.md を更新する

結晶化によって大きな変化があった場合に限り、Overview.md の該当するドメインセクションを更新します。大きな変化には、重大な決定、調査フェーズの完了、新しいドメインの確立などがあります。段階的な追加では更新しません。

Step 7 - log.md の先頭に追記する

新しいエントリーを log.md の先頭に追加します。ヘッダー行の下、既存のすべてのエントリーより上に記載します。

## [YYYY-MM-DD] crystallize | <Topic or Chat Name>
Updated [[Existing Page]] with new findings. [or: Created [[New Page]].]
[Brief note on what was captured. Updated Overview.md: yes/no.]

ステップ 7b - 大きすぎるログのアーカイブを提案する

log.md は先頭に追記する形式で、際限なく大きくなります。crystallize と lint の実行ごとに全体を読み込むため、大きすぎるログは継続的なコンテキストコストになります。ステップ 7 の先頭への追記後、log.md 内の ## [ エントリー数を数えます。150 件を超える場合は、アーカイブを提案します（自動では実行しないでください）。

「log.md には N 件のエントリーがあります。最も古い N-50 件を archive/log-YYYY-MM-DD.md に移し、直近 50 件を現行ログとして残せます。今すぐアーカイブしますか？」

はいの場合：移動する（最も古い）エントリーを <wiki_root>/archive/log-YYYY-MM-DD.md に書き込みます。そのファイルがすでに存在する場合（同じ日に以前ログをアーカイブした場合）は、既存の内容の下にエントリーを追記します。存在しない場合は、標準のログヘッダーに続けてエントリーを記載して作成します。その後、log.md をヘッダーと新しい方から 50 件のエントリーで書き直します。アーカイブではエントリーを移動し、削除はしません。監査証跡は log.md とアーカイブの両方にわたって保持され、同じ日に 2 回目のアーカイブを行う場合は、既存ファイルを上書きせずに追記します。いいえの場合：log.md は変更しません。件数が 150 件以下の場合は、何もせず、何も言いません。

ステップ 8 - 締めくくり方を選ぶ

2 つのシグナルを確認し、どのように締めくくるかを決めます。

シグナル 1：明示された意図。 ユーザーは、チャット全体を対象とする明示的な表現（「これを閉じる前に」「このスレッドを締めくくる」「アーカイブする」など）を使って crystallize を呼び出しましたか？ はいの場合は、しっかりと締めくくります。

シグナル 2：スレッドの蓄積度。 対象ページの crystallize_count（ステップ 4a ですでに読み取り済み）は、セッションをまたいでこのスレッドが crystallize された回数を示す永続的な指標です。ログをアーカイブしても値は保持されるため、log.md のエントリー数より優先してください。回数が多い（以前に何度も crystallize されている）場合は、スレッドに情報が蓄積されており、新たに始めるのが適切です。その場合は、しっかりと締めくくります。回数が 1（初回の crystallize、または新規作成されたページ）の場合や、セッションが対象を絞った軽い内容の場合は、セッションの締めくくりとします。

注：このスキルからコンテキストウィンドウの残量を正確に測ることはできません。観察できるシグナルに基づいて定性的に判断してください。

セッションの締めくくり - スレッドにはまだ価値があり、保持すべき確立されたコンテキストがあります。

「記録しました。[[Topic]] に今日の決定事項と調査結果を反映しました。このチャットを続けても、新しいチャットを始めても、どちらでも大丈夫です。続ける場合も、ここにあるコンテキストは引き続き役立ちます。新しく始める場合は、まず [[Topic]] を読んでください。」

しっかりとした締めくくり - スレッドに情報が蓄積されているか、明示的にアーカイブする場合：

「このチャットは終了できます。[[Topic]] に保持すべき内容をすべてまとめました。次のセッションを始める際は、そのページを読んでください。このスレッドをそのまま引き継ぐより、コンテキストをすばやく把握できます。」

---

主なルール

1. 書き写すのではなく、要点をまとめる： wiki ページは元の内容より大幅に短く、構成を整理してください
2. 長く役立つ情報を残し、下準備は省く： 価値が積み重なる情報を厳選してください
3. すべてのページにフロントマターを付ける： title、version、date（作成日。変更不可）、updated（今日の日付）、crystallize_count（作成時は 1、更新時は読み取ってからインクリメント）、changes: "Crystallized from [source]"
4. ブラックリストに登録されたパスには絶対に書き込まない
5. Overview.md の更新は控えめにする： 知識に本当に重要な変化があった場合に限ります
6. ウィキリンクで検索可能にする： 関連ページへのリンクを必ず追加します