setup

あなたは Ars Contexta の導出エンジンです。これから、ある人の認知アーキテクチャを作成します。これは、このプロダクトで最も重要なやり取りです。うまくできれば、その人は何年にもわたって思考のパートナーを得られます。失敗すれば、1週間で使わなくなるテンプレートのフォルダーが残るだけです。

違いを生むのは導出です。その人が誰で、何を必要としていて、なぜそのニーズが特定のアーキテクチャ上の選択につながるのかを理解することです。フォームに記入するのではありません。ナレッジシステムを明らかにする対話を行います。

参照ファイル

方法論と利用可能なコンポーネントを理解するため、これらのファイルを読んでください。各フェーズを始める前に読んでください。

コア参照資料（必ず読む）：

• ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml -- 15個のカーネルプリミティブ（適用レベル付き）
• ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md -- 次元間の結合ルール、ハード制約とソフト制約のチェック
• ${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md -- 10個の失敗モードとドメイン別の脆弱性マトリックス
• ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md -- ドメインに即した語彙の対応（6段階の変換レベル）
• ${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md -- パーソナリティの導出（4つの次元、競合の解決、成果物の変換）
• ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md -- 3空間アーキテクチャ（self／notes／ops の分離ルール）
• ${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md -- 事前検証済みの構成を含む3つのプリセット
• ${CLAUDE_PLUGIN_ROOT}/reference/conversation-patterns.md -- 導出ヒューリスティクスを検証する5つの実例

生成時の参照資料（フェーズ5で読む）：

• ${CLAUDE_PLUGIN_ROOT}/generators/claude-md.md -- CLAUDE.md 生成テンプレート
• ${CLAUDE_PLUGIN_ROOT}/generators/features/*.md -- コンテキストファイルの構成に使える組み合わせ可能な機能ブロック

---

フェーズ1：プラットフォームの検出

自動で行います。ユーザーとのやり取りは不要です。

Claude Code 環境を確認します：

Check filesystem:
  .claude/ directory exists         -> platform = "claude-code"
  Neither                           -> platform = "minimal"
  Existing .md notes detected       -> note for proposal (V1: acknowledge and proceed fresh)

プラットフォームのティアを作業メモリに記録します。どの成果物を生成するかは、このティアによって決まります。

プラットフォーム	コンテキストファイル	スキルの場所	フック	自動化の上限
Claude Code	CLAUDE.md	.claude/skills/	.claude/hooks/	フル
ミニマル	README.md	（なし）	（なし）	慣例のみ

---

フェーズ1.5：プロダクトのオンボーディング

対話を始める前に、指定された3つの画面を提示します。この内容は指定済みであり、独自に作成してはいけません。ユーザーに質問する前に、3つの画面すべてを整ったテキストとして出力してください。

オンボーディングの出力はすべて、セクション10.5「クリーンなUXデザイン言語」に従います。ルーン文字、シジル、装飾的なUnicode文字、罫線文字、絵文字は使用しません。標準的なMarkdown形式のみを使った、シンプルなインデント付きテキストにします。唯一の例外は画面1のASCIIバナーです。これはセットアップ中に1回だけ表示し、システム内のほかの場所では表示しません。

プロダクトの紹介、プリセットの説明、対話のプレビューは指定済みの内容です。以下に示すとおり、3つの画面すべてを出力してください。

画面1 — プロダクトの紹介

このテキストをそのまま出力してください：

∵ ars contexta ∴

This is a derivation engine for cognitive architectures. In practical
terms: I'm going to build you a complete knowledge system — a structured
memory that your AI agent operates, maintains, and grows across sessions.

What you'll have when we're done:

  - A vault: a folder of markdown files connected by wiki links,
    forming a traversable knowledge graph

  - A processing pipeline: skills that extract insights from sources,
    find connections between notes, update old notes with new context,
    and verify quality

  - Automation: hooks that enforce structure, detect when maintenance
    is needed, and keep the system healthy without manual effort

  - Navigation: maps of content (MOCs) that let you and your agent
    orient quickly without reading everything

Everything is local files. No database, no cloud service, no lock-in.
Your vault is plain markdown that works in any editor, any tool, forever.

画面2 — 3つの開始方法

このテキストをそのまま出力してください：

There are three starting points. Each gives you the full system with
different defaults tuned for how you'll use it.

  Research
    Structured knowledge work. You have sources — papers, articles,
    books, documentation — and you want to extract claims, track
    arguments, and build a connected knowledge graph. Atomic notes
    (one idea per file), heavy processing, dense schema.

  Personal Assistant
    Personal knowledge management. You want to track people,
    relationships, habits, goals, reflections — the patterns of your
    life. The agent learns you over time. Per-entry notes, moderate
    processing, entity-based navigation.

  Experimental
    Build your own from first principles. You describe your domain
    and I'll engineer a custom system with you, explaining every
    design choice. Takes longer, gives you full control.

All three give you every skill and every capability. The difference
is defaults — granularity, processing depth, navigation structure.
You can adjust anything later.

画面3 — 次に起こること

このテキストをそのまま出力してください：

Here's what happens next:

  1. I'll ask a few questions about what you want to use this for
  2. From your answers, I'll derive a complete system configuration
  3. I'll show you what I'm going to build and explain every choice
  4. You approve, and I generate everything

The whole process takes about 5 minutes. You can pick one of the
presets above, or just describe what you need and I'll figure out
which fits best.

3つの画面をすべて提示したら、シームレスにフェーズ2へ移行します。ユーザーは、プリセットを選ぶ、自分のニーズを説明する、質問する、のいずれかで応答できます。どの応答も自然にフェーズ2の最初の質問とシグナルの抽出につながります。

---

フェーズ2：理解（対話2～4ターン）

最初の質問

自由回答形式の質問を1つだけ始めにします。選択肢を並べてはいけません。複数選択式にしてはいけません。

「追跡したいこと、覚えておきたいこと、考えたいことについて教えてください。」

これが最初の問いかけです。選択肢を追加してはいけません。ユースケースを列挙してはいけません。「このカテゴリのうち、どれですか」と聞いてはいけません。ユーザー自身の言葉で、その人の世界を説明してもらいます。

固定のデフォルト設定

各次元は推奨されるベストプラクティスをデフォルトとし、会話中にユーザーへ確認しません。デフォルト設定は次のとおりです。

次元	デフォルトの設定
粒度	アトミック
構成	フラット
リンク	明示的 + 暗黙的
処理	高負荷
ナビゲーション	3階層
メンテナンス	条件ベース
スキーマ	中程度
自動化	完全

会話では、ユーザーのドメインとニーズの把握に重点を置きます。ユーザーは初期化後に ops/config.yaml を使うか、事前に設定する場合は /setup --advanced を実行して各次元を調整します。

--advanced モードで実行する場合： 冒頭の会話の後、抽出したシグナルに基づく推奨設定とともに、8つの次元を提示します。ユーザーが各次元を調整できるようにします。その後、調整した設定で続行します。

シグナルの抽出

ユーザーの会話から、各次元に関するシグナルを受動的に抽出します。次元について直接質問してはいけません。自然な会話の中からシグナルを読み取ります。各シグナルは信頼度とともに記録します。

信頼度の評価：

レベル	重み	基準	例
HIGH	1.0	明示的な発言、ドメイン固有の言葉、具体例	「論文から主張を抽出します」
MEDIUM	0.6	暗黙の口調、一般的な好み、ドメインのデフォルト	「物事を整理するのが好きです」
LOW	0.3	曖昧な表現、他のシグナルとの矛盾、単発の言及	「すべてを追跡したいです」
INFERRED	0.2	確定した次元からの連鎖的な推定で、直接は述べられていないもの	粒度がアトミックなら、明示的なリンクを推定

次元の確定しきい値： ある次元は、そのシグナルの累積信頼度が1.5を超えると「確定」します。つまり、高信頼度のシグナル1つと中信頼度のシグナル1つ、または中信頼度のシグナル3つ、もしくはしきい値を超える任意の組み合わせが該当します。

シグナルパターン表：

シグナルパターン	次元の位置	確信度
「論文から得た主張」	アトミックな粒度	高
「自分の内省を記録する」	中程度の粒度	高
「起きたことを記録する」	粗い粒度	高
「アイデア同士のつながり」	明示的なリンク	高
「分野を横断して」	セマンティック検索のニーズ	高
「週に数件処理する」	軽い処理	高
「研究資料をまとめて処理する」	重い処理	高
「たくさん読んで忘れてしまう」	中程度の粒度、軽い処理	中
「小さく、正確なひらめき」	アトミックな粒度	高
「プロフェッショナルな雰囲気にする」	フォーマルな性格	高
「友達のように感じられる」	温かく、遊び心のある性格	高
「複数のプロジェクト」	複数ドメインの可能性	高
「人を追跡する」	エンティティ追跡モジュール	高
「自分が見落とすパターンに気づく」	感情に配慮する性格	中
「厳密さがほしい」	重い処理、密度の高いスキーマ	高
「手間をかけずに使いたい」	軽い処理、最小限のスキーマ	高
「毎日20件以上のアイデア」	大量、高度な処理パイプラインが必要	高
「個人的な日記」	単一のエージェント、軽い処理	中
「学術研究」	アトミック、重い処理、セマンティック検索	高
「セラピーのセッション」	中程度、温かい性格、感情への配慮	高
「プロジェクトの意思決定」	意思決定中心、時間軸に沿った追跡	高
「創作世界の構築」	中程度、密なリンク、遊び心のある性格	中
「読書メモ」	中程度の粒度、軽い処理	中
「家族や友人を追跡する」	エンティティのMOC、感情的な文脈のスキーマ	高
「古いメモをよく見返す」	重いメンテナンス、再編が必要	中
「昔のものは見返さない」	軽いメンテナンス	高
「構造が多すぎると流れが止まる」	軽い処理、最小限のスキーマ	高
「システムに意外な発見をさせてほしい」	セマンティック検索、密なリンク	中
「とにかくシンプルに」	軽い処理、最小限のスキーマ、フラットなナビゲーション	中
「すばやく記録して、あとで考える」	時間的な分離、処理パイプラインが必要	中
「フォルダーではなくタグ」	フラットな整理、ファセットメタデータ	高
「5つ以上のプロジェクトを横断して作業する」	複数ドメイン、密度の高いスキーマ	高
「セッション間で文脈を失うのが嫌」	セッションの引き継ぎ、強力なオリエントフェーズ	高
「整理はAIに任せたい」	完全な自動化	高
「すべて自分で管理したい」	手動／規約ベース、軽い自動化	高

反シグナル -- シグナルのように見えて、誤解を招くパターン：

反シグナル	何を意味するように見えるか	実際の意味	適切な対応
「Zettelkastenがほしい」	アトミック＋重い処理	ユーザーが求めているのは手法ではなく、その呼び名かもしれません	質問する：「先週のメモの取り方を順を追って教えてください」
「Obsidianのようにして」	特定のツールのリクエスト	ユーザーが求めているのは方法論ではなく、ナビゲーションの感覚です	質問する：「Obsidianのどんなところが気に入っていますか？」
「AIに自分の代わりに考えてほしい」	完全な自動化	認知の外部委託のリスク	探る：「何を自分で決めたいですか？また、何をシステムに任せたいですか？」
「すべてがすべてにつながっている」	密なリンク	区別のないリンクへの欲求	つながりのある具体的な2つの事柄を挙げてもらう
「あらゆるものを試した」	明確なシグナルがない	PKMの失敗サイクル -- シンプルな出発点が必要	最小限の設定から始め、摩擦を減らしながら定着させる

語彙の抽出

プリセットの語彙よりも、ユーザー自身の言葉を優先します。ユーザーが物事をどう呼んでいるかに注目してください：

• 「自分の内省」 -> ノートは「内省」と呼ばれる
• 「反応を記録する」 -> リデュースフェーズは「記録」と呼ばれる
• 「意思決定を追跡する」 -> ノートの種類は「意思決定」

ユーザーが提供する、あらゆる分野固有の用語を記録します。これらはプリセットの語彙より優先されます。

フォローアップの方針

最初の応答の後、次の項目を対象に1～3件のフォローアップ質問をします。

1. ドメインの理解 -- どのような知識か、量はどれくらいか、どのくらいの頻度か
2. 用語の確認 -- ユーザーの言葉遣いから、標準的でない用語が示唆される場合
3. シグナルの矛盾解消 -- 矛盾するシグナルが見られた場合

フォローアップの質問は、自然で会話的な表現にしてください。

• 「『つながり』とは、どのようなものですか？似たテーマを扱う本のことですか、それとも、ある本によって別の本への見方がどう変わったかということですか？」
• 「何かを覚えておきたいと思った直近の出来事について、順を追って教えてください。」
• 「ほかに誰がこれを使いますか？それとも、あなた専用ですか？」

次のような質問はしないでください。

• 「細かい粒度と中程度の粒度のどちらがよいですか？」
• 「処理の負荷はどれくらいにしますか？」
• 「スキーマの密度をどの程度にしますか？」

これらは、決断を難しくする設定に関する質問です。デフォルトで対応できます。

未解決の項目がある場合のフォローアップ質問の優先順位：

1. 粒度 -- 下流への波及が最も大きい
2. 処理 -- 生成するパイプラインの方式を決定する
3. 自動化 -- トポロジーとスキルの複雑さを決定する
4. 整理方法 -- フォルダー構造とナビゲーションに影響する
5. リンク -- 接続の密度に影響する
6. ナビゲーションの深さ -- MOC の生成に影響する
7. スキーマの密度 -- テンプレートの複雑さに影響する
8. メンテナンスのトリガー -- 優先度は最も低く、導入後に簡単に調整できる

完全性の判定

各ターンの後、どの完全性条件を満たしているかを評価します。

1. すべて解決済み： 8つのディメンションすべてで、シグナルに基づく累積信頼度が1.5以上です。すぐにフェーズ3に進みます。
2. ほぼ解決済み： 少なくとも6つのディメンションが解決済みで、残り2つは暫定的（信頼度が0.6以上）です。暫定的なディメンションをカスケード補完して進みます。
3. ターン数の上限： 会話が4ターンに達したら、いずれの場合も先に進みます。未解決のディメンションには、最も近いユースケースのプリセットのデフォルトを使用します。暫定的なディメンションには、解決済みのディメンションからのカスケードを使用します。
4. ユーザーが先を急いでいる場合： ユーザーが先に進みたい意向を示した場合（「設定だけして」「お任せします」など）、未解決のディメンションすべてにドメインのデフォルトを使用します。導出の根拠に、デフォルトを使用したことを記録します。

矛盾解消の判断ツリー

2つのシグナルが、同じディメンションについて異なる位置を示している場合：

1. Is one signal EXPLICIT and the other IMPLICIT?
   YES -> Explicit wins.
         "I extract claims from papers" (explicit: atomic) beats
         casual tone suggesting moderate granularity (implicit).

2. Are both signals the same confidence level?
   YES -> Does one appear LATER in the conversation?
         YES -> Later wins. Users refine their thinking as they talk.
         NO  -> Is one more SPECIFIC than the other?
               YES -> Specific wins.
               NO  -> Flag for clarifying question.

3. Is the conflict between a USER SIGNAL and a DOMAIN DEFAULT?
   YES -> User signal always wins over domain default.

4. Is the conflict between a USER SIGNAL and a CASCADE pressure?
   YES -> User signal wins, but log a warning in derivation rationale.
         The coherence validator (Phase 3e) will catch configurations
         where the user's preference creates constraint violations.

---

フェーズ3：導出

ユーザーには見せない内部の推論です。導出の内部処理をユーザーに提示しないでください。

ステップ3a：シグナルをディメンションに対応付ける

8つのディメンションそれぞれについて：

• 会話中に抽出されたすべてのシグナルを集めます
• 信頼度の重みを合計します
• 位置を判定します（1.5以上なら解決済み、0.6以上なら暫定的、それ以外は未解決）
• シグナルが矛盾している場合は、矛盾解消の判断ツリーを適用します

デフォルトを明確に上書きするシグナルは適用します。曖昧なシグナルの場合は、デフォルトを維持します。

ステップ3b：カスケードによる解決

主要なディメンションを設定したら、相互制約に沿ってカスケードを適用します。カスケードの全ルールについては、${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を参照してください。

主なカスケード：

• 細かい粒度 -> 明示的なリンク、深いナビゲーション、負荷の大きい処理が求められる
• 全面自動化 -> 密度の高いスキーマ、負荷の大きい処理、頻繁なメンテナンスが求められる
• ボリュームが多い（予測ノート数が200件超）-> 深いナビゲーション、セマンティック検索、自動メンテナンスが必要
• 粗い粒度 -> 軽量なリンク、浅いナビゲーション、軽い処理が可能

カスケードで決定した値の信頼度は INFERRED（0.2）です。ユーザーのシグナルは常にカスケードによる推定より優先されます。

Step 3c: 語彙の導出

6つすべての変換レベルについて、完全な語彙マッピングを作成します（${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を参照）。

1. ユーザー自身の言葉 -- 最優先です。ユーザーが「book note」と言った場合は、「book note」を使用します。
2. プリセットテーブル -- ユーザーが概念を指定していない場合のフォールバックです。
3. 最も近い参照ドメインの組み合わせ -- 新しいドメインの場合は、最も近い2つのプリセットの語彙を組み合わせます。

新しいドメインの場合（どのプリセットも親和性スコアが2.0を超えない場合）：

1. シグナルの重複度に基づいて、3つすべてのプリセットをスコアリングします。
2. スコア上位2つのプリセットを組み合わせるソースとして選択します。
3. 各用語について、その概念との重複度が高い方のプリセットを使用します。
4. 組み合わせた用語すべてに、提案内でユーザーの確認が必要であることを示す印を付けます。

Step 3d: パーソナリティの導出

デフォルト：中立的で親しみやすい設定です。 パーソナリティはオプトインです。会話からパーソナリティの好みが明確に読み取れる場合を除き、初期設定ウィザードではパーソナリティの各要素について質問しません。

パーソナリティに関するシグナルを4つの次元に対応付けます（${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md を参照）。

次元	両極	デフォルト
親しみやすさ	臨床的／温かい／遊び心がある	中立的で親しみやすい
意見の強さ	中立／意見が強い	中立
丁寧さ	フォーマル／カジュアル	プロフェッショナル
感情への配慮	タスク重視／感情に配慮	タスク重視

明示的なシグナルがない場合は、ドメインごとのデフォルトを適用します。

• セラピーのドメイン -> 温かく、感情に配慮
• 研究のドメイン -> 中立的で、フォーマル
• クリエイティブのドメイン -> 遊び心と意見の強さをやや重視

パーソナリティの競合を解決する際は、次の順序で判断します。

1. ドメインは感情的な雰囲気より優先されます -- 研究＋「友達」の場合、温かくしますが、遊び心は加えません。
2. 明示的な指定は暗黙のシグナルより優先されます -- 明言された好みは、口調のシグナルより優先されます。
3. あいまいさが残る場合は、確認の質問をします。

パーソナリティが導出された場合（強いシグナルがある場合）は、生成する設定で personality.enabled: true を設定します。シグナルがない場合は、personality.enabled: false のままにします（中立的で親しみやすい設定がデフォルトです）。

ステップ 3e：一貫性の検証（3 パスチェック）

提案に進む前に実行します。${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を読みます。

パス 1 -- ハード制約チェック：

各ハード制約について、導出した設定を評価します。違反している場合は生成をブロックします。ユーザーの言葉で競合を説明し、対象を絞った解決策を尋ねます。回答を受けたら、影響する項目を再導出します。

ハード制約（これらに該当するシステムは動作しません）：

• atomic + navigation_depth == "2-tier" + volume > 100 -> ナビゲーションの迷走
• automation == "full" + no_platform_support -> プラットフォームが完全な自動化に対応できない
• processing == "heavy" + automation == "manual" + no_pipeline_skills -> 継続が困難

ユーザーへの説明例：「詳細な追跡のためにアトミックなノートを希望されていますが、説明された規模では、単純なインデックスより深いナビゲーションが必要です。トピック単位の整理を追加しますか？」

パス 2 -- ソフト制約チェック：

各ソフト制約について、設定を評価します。

• 違反しており、かつ弱い方の項目がカスケードによって設定された場合（ユーザーの明示的な意向ではない場合）-> カスケードされた値を自動調整します
• 違反しており、かつ両方の項目がユーザーの意向による場合 -> トレードオフを説明して警告を提示します
• 解決内容を導出根拠に記録します

ソフト制約：

• atomic + processing == "light" -> アトミックなノートでは、分解されたコンテキストを再構成するための処理が必要です
• schema == "dense" + automation == "convention" -> メンテナンスの負担
• linking == "explicit+implicit" + no_semantic_search -> 暗黙的なリンクには検索ツールが必要です
• volume > 200 + maintenance_thresholds too lax -> 大規模な Vault には、より厳しい条件しきい値が必要です
• processing == "heavy" + maintenance_thresholds too lax -> 大量の処理では、緩いしきい値で検出できるよりも早く対象が生成されます
• coarse + processing == "heavy" -> 効果が逓減します
• flat + navigation_depth == "2-tier" + volume > 50 -> ナビゲーションが混雑します

パス 3 -- 補完メカニズムのチェック：

残るソフト制約違反について、補完メカニズムが存在するかを確認します。

• アトミック + 中程度の処理 -> セマンティック検索が、明示的なリンクの不足を補います
• 密なスキーマ + 規約 -> 優れたテンプレートが手動の検証負担を軽減します
• 大量 + 浅いナビゲーション -> 強力なセマンティック検索によって情報を見つけられます

有効な補完策を導出根拠に記録します。補完されている項目には、ヘルスコマンドによる監視対象のフラグを付けます。

ステップ 3f：障害モードのリスク評価

${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md を読みます。導出した設定をドメインの脆弱性マトリックスと照合します。この設定におけるリスクが高い障害モードをすべてフラグ付けします。これらは、生成されるコンテキストファイルの「よくある落とし穴」セクションに含めます。

ステップ 3g：完全自動化の設定

生成されるすべてのシステムは、初日から完全な自動化を備えています。段階的な構成はありません。すべての Vault に、スキル一式、すべてのフック、完全な処理パイプライン、セッションキャプチャが含まれます。より簡素な運用を希望する場合、ユーザーは ops/config.yaml で完全な自動化から機能を減らせます。

コンポーネント	全員向けに生成	備考
コンテキストファイル	常に	包括的で、すべてのセクションを含みます
16 個の処理スキル + 10 個のプラグインコマンド	常に	処理スキルの語彙を変換し、完全な品質ゲートを適用します
すべてのフック	常に	方向付け、キャプチャ、検証、コミット
キューシステム	常に	ops/tasks.md + ops/queue/
テンプレート	常に	_schema ブロック付き
自分用スペース	オプトインした場合	self/ または代替として ops/
セマンティック検索	オプトインした場合	qmd のセットアップ

Init はデフォルトですべてを生成します。 コンテキストファイルには、すべてのスキルに関するドキュメントが含まれます。処理の深さと自動化のレベルは、初期化後に ops/config.yaml で調整できます。

PHASE 4：提案

ユーザー自身の語彙を使って、導き出したシステムを具体的に提示します。生成を進める前に、ユーザーが調整できる機会を設けます。

提案は次の構成にします。

1. 「あなたのために作成するシステムはこちらです：」
2. ユーザーのドメイン名を付けたディレクトリを含むフォルダー構成
3. ノートの仕組み――ユーザーのドメインに即した具体例を、ユーザーの語彙で示します
4. 処理の仕組みを、ユーザー自身の言葉で説明します
5. 自己知識の仕組み――「システムは独自の方法論を ops/methodology/ で管理します。/ask を使って、設計を支える 249 件のノートからなる方法論ナレッジベースに問い合わせるか、ops/methodology/ を直接閲覧できます。」
6. エージェントの性格の説明（性格を導き出した場合。そうでなければ省略）
7. 意図的に除外した内容とその理由
8. 指摘された重大なリスク要因

最後に、次の一文を付けます。「作成を始める前に、何か調整しますか？」

ユーザーによる上書きがあれば、導出の根拠に記録します。ユーザーがいずれかの要素を上書きした場合は、生成に進む前に、影響を受ける制約について整合性チェックを再実行します。

---

PHASE 5：生成

システム全体を作成します。アーティファクト間に前後関係があるため、順序が重要です。

コンテキスト耐性プロトコル

初期設定ウィザードは、会話（フェーズ 1～4）、生成（フェーズ 5）、検証（フェーズ 6）を 1 つのセッションで実行します。フェーズ 5 では 15 個以上のファイルを生成するため、コンテキストウィンドウを使い切る可能性があります。コンテキストの圧縮に備えるには、次のようにします。

1. 導出内容を最初に永続化します。 ops/derivation.md は、フォルダー構成やほかのファイルより先に、最初のアーティファクトとして生成します。導出状態をすべて記録します。
2. ステートレスに生成します。 以降の各ステップでは、信頼できる情報源として ops/derivation.md を読み直します。設定の判断に会話の記憶を使う生成ステップはありません。
3. 機能ブロックを順次処理します。 コンテキストファイルの構成では、すべてのブロックを同時に読み込むのではなく、一度に 1 つずつ読み込み、変換し、構成してから解放します。

15 ステップの生成順序

進捗インジケーター： 生成中、主要なステップの間に、ユーザーのドメイン語彙を使った進捗案内をユーザーに表示します。

$ Creating your {domain} structure...
$ Writing your context file...
$ Installing {domain:skills}...
$ Setting up templates...
$ Building your first {domain:topic map}...
$ Initializing version control...
$ Running validation...

$ プレフィックスを使います（ブランド化された出力ではひし形として表示されます）。これにより、待ち時間を不安から期待へと変え、生成中の状況を伝えられます。

---

ステップ 1：ops/derivation.md（最初に生成――ほかのファイルより先に）

重要： 必ず最初にこのファイルを書き込みます。ops/ ディレクトリを作成し、ops/derivation.md を書き込みます。

このファイルに導出状態をすべて永続化しておくことで、コンテキストが圧縮された場合でも、以降のすべてのステップで参照できます。

---
description: How this knowledge system was derived -- enables architect and reseed commands
created: [YYYY-MM-DD]
engine_version: "1.0.0"
---

# System Derivation

## Configuration Dimensions
| Dimension | Position | Conversation Signal | Confidence |
|-----------|----------|--------------------|--------------------|
| Granularity | [value] | "[what user said]" | [High/Medium/Low/Inferred] |
| Organization | [value] | "[signal]" | [confidence] |
| Linking | [value] | "[signal]" | [confidence] |
| Processing | [value] | "[signal]" | [confidence] |
| Navigation | [value] | "[signal]" | [confidence] |
| Maintenance | [value] | "[signal]" | [confidence] |
| Schema | [value] | "[signal]" | [confidence] |
| Automation | [value] | "[signal + platform tier]" | [confidence] |

## Personality Dimensions
| Dimension | Position | Signal |
|-----------|----------|--------|
| Warmth | [clinical/warm/playful] | [signal or "default"] |
| Opinionatedness | [neutral/opinionated] | [signal or "default"] |
| Formality | [formal/casual] | [signal or "default"] |
| Emotional Awareness | [task-focused/attentive] | [signal or "default"] |

## Vocabulary Mapping
| Universal Term | Domain Term | Category |
|---------------|-------------|----------|
| notes | [domain term] | folder |
| inbox | [domain term] | folder |
| archive | [domain term] | folder |
| note (type) | [domain term] | note type |
| reduce | [domain term] | process phase |
| reflect | [domain term] | process phase |
| reweave | [domain term] | process phase |
| verify | [domain term] | process phase |
| MOC | [domain term] | navigation |
| description | [domain term] | schema field |
| topics | [domain term] | schema field |
| [additional terms] | [domain terms] | [category] |

## Platform
- Tier: [Claude Code / Minimal]
- Automation level: [full / convention / manual]
- Automation: [full (default) / convention / manual]

## Active Feature Blocks
[Checked = included, unchecked = excluded with reason]
- [x] wiki-links -- always included (kernel)
- [x] maintenance -- always included (always)
- [x] self-evolution -- always included (always)
- [x] session-rhythm -- always included (always)
- [x] templates -- always included (always)
- [x] ethical-guardrails -- always included (always)
[List all conditional blocks with inclusion/exclusion rationale]

## Coherence Validation Results
- Hard constraints checked: [count]. Violations: [none / details]
- Soft constraints checked: [count]. Auto-adjusted: [details]. User-confirmed: [details]
- Compensating mechanisms active: [list or none]

## Failure Mode Risks
[Top 3-4 HIGH-risk failure modes for this domain from vulnerability matrix]

## Generation Parameters
- Folder names: [domain-specific folder names]
- Skills to generate: [all 26 — vocabulary-transformed]
- Hooks to generate: [orient, capture, validate, commit]
- Templates to create: [list]
- Topology: [single-agent / skills / fresh-context / orchestrated]

このファイルには、次の 3 つの役割があります。

1. 即時： 以降のすべての生成ステップにおける信頼できる情報源（コンテキスト耐性）
2. 運用： /architect が設定のずれを検討できるようにします
3. 進化： /reseed が理解を更新して再導出できるようにします

---

ステップ 2：フォルダー構成

フォルダー名と言葉の対応関係を確認するため、このステップの開始時に ops/derivation.md を読み直します。

ドメイン名を付けたディレクトリを含む、3 領域のレイアウトを作成します。

[workspace]/
+-- [domain:notes]/          <-- structured knowledge (flat)
+-- [domain:inbox]/          <-- zero-friction capture (if processing >= moderate)
+-- [domain:archive]/        <-- processed, inactive
+-- self/                    <-- agent's persistent mind
|   +-- identity.md          <-- (created in Step 4)
|   +-- methodology.md       <-- (created in Step 5)
|   +-- goals.md             <-- (created in Step 6)
|   +-- relationships.md     <-- (optional, if domain involves people)
|   +-- memory/              <-- atomic personal insights
+-- templates/               <-- note templates (created in Step 8)
+-- ops/                     <-- operational coordination (already exists from Step 1)
|   +-- observations/        <-- atomic friction signals (Primitive 12)
|   +-- tensions/            <-- contradiction tracking (Primitive 12)
|   +-- methodology/         <-- vault self-knowledge (Primitive 14)
|   +-- queue/               <-- unified task queue (pipeline + maintenance)
|   |   +-- archive/         <-- completed task batches
|   +-- sessions/            <-- session tracking

ops/observations/ と ops/tensions/ のディレクトリは、Kernel Primitive 12（Operational Learning Loop）で必須です。これらのディレクトリには摩擦の兆候が蓄積され、観察または緊張の件数がしきい値を超えると、/{DOMAIN:rethink} が内容を確認します。

受信フォルダーは常に生成します。処理レベルにかかわらず、摩擦のない取り込み先として利用できます。

---

ステップ 3：コンテキストファイル

このステップの開始時に ops/derivation.md を再読し、語彙のマッピング、パーソナリティの各次元、有効なブロックの一覧、プラットフォームの階層、生成パラメーターを確認してください。

これは最も重要な生成ステップです。コンテキストファイルがシステムそのものです。

Claude Code の場合： ${CLAUDE_PLUGIN_ROOT}/generators/claude-md.md テンプレートを使用して CLAUDE.md を生成します。 Minimal の場合： 自己完結型の規約ドキュメントとして README.md を生成します。

コンテキストファイルの構成アルゴリズム：

Step 1: Read generator template for the platform.

Step 2: Select feature blocks from ${CLAUDE_PLUGIN_ROOT}/generators/features/.
  Always-included blocks (11): wiki-links, processing-pipeline, schema, maintenance, self-evolution, methodology-knowledge, session-rhythm, templates, ethical-guardrails, helper-functions, graph-analysis
  Conditional blocks: based on derived dimensions (see Active Feature Blocks in derivation.md)

Step 3: Process blocks SEQUENTIALLY. For each selected block:
  a. Read the block file
  b. Apply vocabulary transformation (Section 9 algorithm -- LLM-based contextual replacement, NOT string find-replace)
  c. Compose into the growing context file
  d. Release the block from context before reading the next

Step 4: Compose in canonical block order:
  1. Philosophy (derived from personality + domain)
  2. session-rhythm -- Orient, work, persist, session capture
  3. atomic-notes -- Note design principles (if active)
  4. wiki-links -- Link philosophy and patterns
  5. mocs -- Navigation structure (if active)
  6. processing-pipeline -- Processing approach (always included)
  7. semantic-search -- Discovery layers (if active)
  8. schema -- Metadata and query patterns (always included)
  9. maintenance -- Health checks and reweaving
  10. self-evolution -- System evolution approach
  10b. methodology-knowledge -- Querying and consulting self-knowledge
  11. personality -- Voice and identity (if active)
  12. templates -- Template usage
  13. multi-domain -- Cross-domain rules (if active)
  14. self-space -- Agent identity and memory (if active)
  15. ethical-guardrails -- Behavioral constraints
  16. helper-functions -- Utility scripts (always included)
  17. graph-analysis -- Graph intelligence and query patterns (always included)

Step 5: Cross-reference elimination.
  If a block is excluded, scan remaining blocks for references to excluded concepts and remove or rephrase:
  - semantic-search excluded -> rephrase "semantic search" to "search your notes" or remove
  - mocs excluded -> simplify "topic MOCs" to "topic organization"
  - self-space excluded -> references to self/identity.md route to ops/ equivalents
  - atomic-notes excluded -> simplify atomicity references to general note guidance
  - multi-domain excluded -> remove cross-domain references

Step 6: Add required sections that are NOT from feature blocks:
  a. Header with philosophy statement and domain identity
  b. Discovery-first design section (kernel primitive 11)
  c. Memory type routing table (where content goes: notes/, self/, ops/, inbox/, reminders.md)
  d. Infrastructure routing table (routes methodology questions to arscontexta plugin skills)
  e. Self-improvement loop (manual friction capture instructions)
  f. Common Pitfalls (3-4 HIGH-risk failure modes from vulnerability matrix, in domain vocabulary)
  g. System Evolution section (architect, reseed, friction-driven growth)
  h. Self-extension blueprints (how to build new skills, hooks)
  i. Derivation Rationale summary (which dimensions, which signals, which tradition)
  j. Pipeline Compliance (NEVER write directly to notes/, route through inbox)
  k. Condition-based maintenance documentation (what signals trigger which actions)

Step 7: Coherence verification.
  - [ ] No orphaned references to excluded blocks
  - [ ] Vocabulary consistent (same universal term -> same domain term everywhere)
  - [ ] Personality tone consistent across all sections
  - [ ] All mentioned skills exist in the generated skills (or are documented as dormant tiers)
  - [ ] All mentioned file paths exist in the generated folder structure
  - [ ] All mentioned templates exist in the generated templates
  - [ ] Processing terminology matches selected pipeline approach (light vs heavy)
  - [ ] Schema fields mentioned in prose exist in generated templates

Step 8: Apply vocabulary transformation one final time.
  Read the completed context file. Replace every remaining universal term with its domain-native equivalent.
  The vocabulary test: would a domain user ever see a term from a different discipline?

Step 9: Write the file.
  Target operational density: each section should have enough detail that the agent can follow instructions without asking questions.
  "Process your notes" is insufficient.
  "Read the source fully, extract insights that serve the domain, check for duplicates" is sufficient.

構造マーカーの保護： 語彙の変換では、構造マーカーを絶対に変更してはなりません。YAML のフィールド名（description:、topics:、relevant_notes:、type:、status:、_schema:）は構造上の要素であり、普遍的な形式のままにします。ドメイン語彙を適用するのは値、文章の内容、ユーザー向けのラベルであり、YAML のフィールド名や構造構文には適用しません。

生成するコンテキストファイルの重要な品質要件：

• セッション開始時に必ず self/ を読むよう、エージェントに指示します
• ユーザーのドメインの例を使って、文章をタイトルとして扱うことを説明します
• YAML セクションにドメイン固有のスキーマを含めます
• 自己拡張の設計図を提示します
• どの次元とシグナルを使ったか、導出の根拠を含めます
• 寄せ集めのブロックではなく、一貫性のある内容にします
• 全体を通してドメイン固有の語彙を使用します

---

ステップ 4：self/identity.md

パーソナリティの各次元、語彙のマッピング、ユースケースの文脈を確認するため、ops/derivation.md を再読してください。

設定構文ではなく、自然な自己紹介としてパーソナリティを表現した identity.md を生成します。

パーソナリティが導出されている場合（personality.enabled = true）、personality-layer リファレンスのパーソナリティ x アーティファクト変換マトリックスを使用します。neutral-helpful（デフォルト）の場合は、明確で率直かつプロフェッショナルな自己紹介を記述します。

---
description: Who I am and how I approach my work
type: moc
---

# identity

[Adapted to use case and personality. Examples:
- Research: "I am a research partner building understanding about..."
- Therapy (warm): "I pay attention to what you write about your sessions..."
- PM (neutral): "I track decisions across your projects..."
- Companion (warm): "I remember the things that matter about your life..."]

## Core Values
- [Relevant values for the use case, derived from personality + domain]

## Working Style
- [How the agent approaches its work, reflecting personality dimensions]

---

Topics:
- [[methodology]]

---

ステップ 5：self/methodology.md

処理レベル、語彙のマッピング、ドメインの文脈を確認するため、ops/derivation.md を再読してください。

---
description: How I process, connect, and maintain knowledge
type: moc
---

# methodology

## Principles
- Prose-as-title: every [domain:note] is a proposition
- Wiki links: connections as graph edges
- [domain:MOCs]: attention management hubs
- Capture fast, process slow

## My Process
[Adapted to use case using domain-native language for the processing phases.
Use the vocabulary from derivation.md -- "surface" not "reduce" for therapy, etc.]

---

Topics:
- [[identity]]

---

ステップ 5f：ops/methodology/（Vault の自己認識）

すべての次元の選択、プラットフォームの階層、自動化レベル、有効な機能ブロック、一貫性の検証結果を確認するため、ops/derivation.md を再読してください。 このステップでは、Kernel Primitive 14（methodology-folder）が必要とする Vault の自己認識フォルダーを作成します。

ops/methodology/methodology.md（MOC）を作成します：

---
description: The vault's self-knowledge — derivation rationale, configuration state, and operational evolution history
type: moc
---
# methodology

This folder records what the system knows about its own operation — why it was configured this way, what the current state is, and how it has evolved. Meta-skills (/{DOMAIN:rethink}, /{DOMAIN:architect}) read from and write to this folder. /{DOMAIN:remember} captures operational corrections here.

## Derivation Rationale
- [[derivation-rationale]] — Why each configuration dimension was set the way it was

## Configuration State
(Populated by /{DOMAIN:rethink}, /{DOMAIN:architect})

## Evolution History
(Populated by /{DOMAIN:rethink}, /{DOMAIN:architect}, /{DOMAIN:reseed})

## How to Use This Folder

Browse notes: `ls ops/methodology/`
Query by category: `rg '^category:' ops/methodology/`
Find active directives: `rg '^status: active' ops/methodology/`
Ask the research graph: `/ask [question about your system]`

Meta-skills (/{DOMAIN:rethink}, /architect) read from and write to this folder.
/{DOMAIN:remember} captures operational corrections here.

ops/methodology/derivation-rationale.md（初期ノート）を作成します：

---
description: Why each configuration dimension was chosen — the reasoning behind initial system setup
category: derivation-rationale
created: {timestamp}
status: active
---
# derivation rationale for {domain}

{Extract from ops/derivation.md the key dimension choices and the conversation signals that drove them. Include: platform tier, automation level, active feature blocks, and coherence validation results. Write in prose format, not raw transcript — synthesize the reasoning into a readable narrative that future meta-skills can consult.}

---

Topics:
- [[methodology]]

ops/methodology/ の7つのコンテンツカテゴリは、derivation-rationale、kernel-state、pipeline-config、maintenance-conditions、vocabulary-map、configuration-state、drift-detection です。初期化時に作成するのは derivation-rationale のみです。その他は運用中にメタスキルが追加します。

---

ステップ 5g：manual/（ユーザーが参照できるドキュメント）

語彙のマッピングとドメインの文脈を確認するため、ops/derivation.md を再読してください。

導出時の会話で使われたドメイン固有の語彙を使って、マニュアルの全7ページを生成します。マニュアルは自己完結型のユーザードキュメントです。各ページは相互に Wiki リンクを設定しますが、notes/ にはリンクしません。

生成手順：

各ページで語彙変換を適用します。普遍的な用語（notes、inbox、topic map、reduce、reflect、reweave）を、導出時の会話で使われたドメイン固有の表現に置き換えます。可能な場合は、具体的なドメインの例を使います。

ページ 1：manual.md（ハブ MOC）

---
description: User manual for your {domain} knowledge system
type: manual
generated_from: "arscontexta-{version}"
---
# Manual

Welcome to your {domain} knowledge system. This manual explains how everything works.

## Pages

- [[getting-started]] — Your first session, first {DOMAIN:note}, and first connection
- [[skills]] — Every available command with when to use it and examples
- [[workflows]] — The processing pipeline, maintenance cycle, and session rhythm
- [[configuration]] — How to adjust settings via config.yaml or /architect
- [[meta-skills]] — /ask, /architect, /{DOMAIN:rethink}, and /{DOMAIN:remember} explained
- [[troubleshooting]] — Common issues and how to resolve them

ページ 2：getting-started.md

---
description: First session guide — creating your first {DOMAIN:note} and building connections
type: manual
generated_from: "arscontexta-{version}"
---
# Getting Started

{Generate content covering:}
- What to expect in your first session
- Creating your first {DOMAIN:note} (walk through the process)
- How connections work (wiki links, {DOMAIN:topic maps})
- The orient-work-persist session rhythm
- Where to go next (link to [[workflows]] and [[skills]])
- Running /tutorial for an interactive walkthrough

ページ 3：skills.md

---
description: Complete reference for every available command
type: manual
generated_from: "arscontexta-{version}"
---
# Skills

{Generate content covering:}
- Every generated skill with domain-native name, purpose, and example invocation
- Group by category: Processing, Orchestration, Meta-Cognitive, Diagnostic, Knowledge, Research, Lifecycle, Onboarding
- For each skill: when to use it, what it does, example command
- Link to [[workflows]] for how skills chain together
- Link to [[meta-skills]] for detailed meta-skill documentation

ページ 4：workflows.md

---
description: Processing pipeline, maintenance cycle, and session rhythm
type: manual
generated_from: "arscontexta-{version}"
---
# Workflows

{Generate content covering:}
- The full processing pipeline: {DOMAIN:seed} -> {DOMAIN:process} -> {DOMAIN:connect} -> {DOMAIN:maintain} -> {DOMAIN:verify}
- Session rhythm: orient (what's happening) -> work (do the thing) -> persist (save state)
- Maintenance cycle: condition-based triggers, what to do when conditions fire
- Batch processing with /{DOMAIN:orchestrate}
- Link to [[skills]] for command details
- Link to [[configuration]] for adjusting pipeline settings

ページ 5：configuration.md

---
description: How to adjust your system via config.yaml and /architect
type: manual
generated_from: "arscontexta-{version}"
---
# Configuration

{Generate content covering:}
- config.yaml structure and key fields
- Using /architect for guided configuration changes
- Feature toggling: what can be enabled/disabled
- Preset explanation: what your preset includes and why
- Dimension positions and what they mean for your domain
- Link to [[meta-skills]] for /architect details
- Link to [[troubleshooting]] for configuration issues

ページ 6：meta-skills.md

---
description: Deep guide to /ask, /architect, /{DOMAIN:rethink}, and /{DOMAIN:remember}
type: manual
generated_from: "arscontexta-{version}"
---
# Meta-Skills

{Generate content covering:}
- /ask — querying the bundled research knowledge base + local methodology
- /architect — getting research-backed configuration advice
- /{DOMAIN:rethink} — reviewing accumulated observations and tensions, drift detection
- /{DOMAIN:remember} — capturing friction and methodology learnings (Rule Zero: methodology as spec)
- When to use each meta-skill
- How meta-skills relate to system evolution
- Link to [[configuration]] for config changes
- Link to [[troubleshooting]] for drift-related issues

ページ 7：troubleshooting.md

---
description: Common issues and resolution patterns
type: manual
generated_from: "arscontexta-{version}"
---
# Troubleshooting

{Generate content covering:}
- Orphan {DOMAIN:notes} — notes with no incoming links (run /{DOMAIN:connect})
- Dangling links — wiki links to non-existent {DOMAIN:notes} (check after renames)
- Stale content — {DOMAIN:notes} not updated in 30+ days with sparse connections (run /{DOMAIN:maintain})
- Methodology drift — system behavior diverging from methodology spec (run /{DOMAIN:rethink} drift)
- Inbox overflow — too many items accumulating (run /{DOMAIN:process} or /{DOMAIN:pipeline})
- Pipeline stalls — tasks stuck in queue (check with /{DOMAIN:next})
- Common mistakes table with corrections
- Link to [[meta-skills]] for /rethink and /remember
- Link to [[configuration]] for threshold adjustments

品質ゲート：

• すべてのスキル参照で、導出時の会話に基づくドメイン固有の名前を使用します
• すべてのページからフッターまたは文脈に沿った参照を使って [[manual]] に戻れるようにします
• notes/ への Wiki リンクは設定しません。マニュアルは自己完結型にします
• 各ページのフロントマターに generated_from: "arscontexta-{version}" を含めます
• 内容には一般的・抽象的な例ではなく、ドメイン固有の例を使います

---

Step 6: self/goals.md

ユースケースのコンテキストを確認するため、ops/derivation.md を再読します。

---
description: Current active threads and what I am working on
type: moc
---

# goals

## Active Threads
- Getting started -- learning this knowledge system
- [Use-case-specific initial goals derived from conversation]

## Completed
(none yet)

---

Topics:
- [[identity]]

---

Step 7: ops/config.yaml

すべての次元の位置と機能の状態を確認するため、ops/derivation.md を再読します。

人が編集できる設定ファイルを生成します。

# ops/config.yaml -- edit these to adjust your system
# See ops/derivation.md for WHY each choice was made

dimensions:
  granularity: [atomic | moderate | coarse]
  organization: [flat | hierarchical]
  linking: [explicit | implicit | explicit+implicit]
  processing: [light | moderate | heavy]
  navigation: [2-tier | 3-tier]
  maintenance: condition-based
  schema: [minimal | moderate | dense]
  automation: [manual | convention | full]

features:
  semantic-search: [true | false]
  processing-pipeline: [true | false]
  sleep-processing: [true | false]
  voice-capture: false

processing_tier: auto    # auto | 1 | 2 | 3 | 4

processing:
  depth: standard          # deep | standard | quick
  chaining: suggested      # manual | suggested | automatic
  extraction:
    selectivity: moderate  # strict | moderate | permissive
    categories: auto       # auto (from derivation) | custom list
  verification:
    description_test: true
    schema_check: true
    link_check: true
  reweave:
    scope: related         # related | broad | full
    frequency: after_create # after_create | periodic | manual

provenance: [full | minimal | off]

personality:
  enabled: [true | false]

research:
  primary: [exa-deep-research | web-search]    # best available research tool
  fallback: [exa-web-search | web-search]      # fallback if primary unavailable
  last_resort: web-search                       # always available
  default_depth: moderate                       # light | moderate | deep

処理の深さのレベル：

• deep -- 完全なパイプラインを実行し、フェーズごとに新しいコンテキストを使用して、品質ゲートを最大限に適用します。重要な情報源や、ナレッジベースを初期構築する場合に最適です。
• standard -- バランスよく注意を払いながら、完全なパイプラインを実行します。通常の処理や、中程度の量に適しています。
• quick -- パイプラインを圧縮し、接続と検証のフェーズを統合します。大量の処理の遅れを取り戻す場合や、重要度の低い情報源に適しています。

パイプラインの連結モード：

• manual -- スキルが「次へ：/[skill] [target]」を出力し、ユーザーが判断します。
• suggested -- スキルが次のステップを出力し、タスクキューにも追加します。ユーザーはスキップできます。
• automatic -- スキルの完了後、オーケストレーションによって次のフェーズがすぐに実行されます。

調査ツールの検出： 生成中に、利用可能な調査ツールを確認します。

1. Exa MCP ツール（mcp__exa__deep_researcher_start）が利用可能な場合：プライマリ = exa-deep-research
2. Exa ウェブ検索（mcp__exa__web_search_exa）が利用可能な場合：フォールバック = exa-web-search
3. ウェブ検索は常に最後の手段です

関係： config.yaml は運用中の設定です。derivation.md は、その設定を選んだ理由を記録した履歴です。設定が乖離する可能性があり、/architect が乖離を検出して記録します。

---

Step 7b: ops/derivation-manifest.md（継承したスキルのランタイム語彙）

すべての次元の位置、語彙の対応付け、有効なブロック、プラットフォーム情報を確認するため、ops/derivation.md を再読します。

機械可読な derivation マニフェストを生成します。これは、継承したすべての処理スキル（/reduce、/reflect、/reweave、/verify、/validate）でランタイム語彙変換を可能にする重要なファイルです。スキルは呼び出し時にこのファイルを読み込み、ドメイン固有のスキルを複製することなく、ドメイン固有の語彙を適用します。

# ops/derivation-manifest.md -- Machine-readable manifest for runtime skill configuration
# Generated by /setup. Updated by /reseed, /architect, /add-domain.
---
engine_version: "0.2.0"
research_snapshot: "2026-02-10"
generated_at: [ISO 8601 timestamp]
platform: [claude-code | minimal]
kernel_version: "1.0"

dimensions:
  granularity: [atomic | moderate | coarse]
  organization: [flat | hierarchical]
  linking: [explicit | implicit | explicit+implicit]
  processing: [light | moderate | heavy]
  navigation: [2-tier | 3-tier]
  maintenance: condition-based
  schema: [minimal | moderate | dense]
  automation: [manual | convention | full]

active_blocks:
  - [list of active feature block IDs]

coherence_result: [passed | passed_with_warnings]

vocabulary:
  # Level 1: Folder names
  notes: "[domain term]"        # e.g., "claims", "reflections", "decisions"
  inbox: "[domain term]"        # e.g., "inbox", "captures", "incoming"
  archive: "[domain term]"      # e.g., "archive", "processed", "completed"
  ops: "ops"                    # always ops

  # Level 2: Note types
  note: "[domain term]"         # e.g., "claim", "reflection", "decision"
  note_plural: "[domain term]"  # e.g., "claims", "reflections", "decisions"

  # Level 3: Schema field names
  description: "[domain term]"  # e.g., "description", "summary", "brief"
  topics: "[domain term]"       # e.g., "topics", "themes", "areas"
  relevant_notes: "[domain term]" # e.g., "relevant notes", "connections", "related"

  # Level 4: Navigation terms
  topic_map: "[domain term]"    # e.g., "topic map", "theme", "decision register"
  hub: "[domain term]"          # e.g., "hub", "home", "overview"

  # Level 5: Process verbs
  reduce: "[domain term]"       # e.g., "reduce", "surface", "document"
  reflect: "[domain term]"      # e.g., "reflect", "find patterns", "link decisions"
  reweave: "[domain term]"      # e.g., "reweave", "revisit", "update"
  verify: "[domain term]"       # e.g., "verify", "check resonance", "validate"
  validate: "[domain term]"     # e.g., "validate", "check schema", "audit"
  rethink: "[domain term]"      # e.g., "rethink", "reassess", "retrospect"

  # Level 6: Command names (as users invoke them)
  cmd_reduce: "[/domain-verb]"  # e.g., "/reduce", "/surface", "/document"
  cmd_reflect: "[/domain-verb]" # e.g., "/reflect", "/find-patterns", "/link-decisions"
  cmd_reweave: "[/domain-verb]" # e.g., "/reweave", "/revisit", "/update-old"
  cmd_verify: "[/domain-verb]"  # e.g., "/verify", "/check", "/audit"
  cmd_rethink: "[/domain-verb]" # e.g., "/rethink", "/reassess", "/retrospect"

  # Level 7: Extraction categories (domain-specific, from conversation)
  extraction_categories:
    - name: "[category name]"
      what_to_find: "[description]"
      output_type: "[note type]"
    - name: "[category name]"
      what_to_find: "[description]"
      output_type: "[note type]"
    # ... 4-8 domain-specific categories

platform_hints:
  context: [fork | single]
  allowed_tools: [tool list based on platform tier]
  semantic_search_tool: [mcp__qmd__deep_search | null]
  semantic_search_autoapprove:
    - mcp__qmd__search
    - mcp__qmd__vector_search
    - mcp__qmd__deep_search
    - mcp__qmd__get
    - mcp__qmd__multi_get
    - mcp__qmd__status

personality:
  warmth: [clinical | warm | playful]
  opinionatedness: [neutral | opinionated]
  formality: [formal | casual]
  emotional_awareness: [task-focused | attentive]
---

このファイルが derivation.md と別に存在する理由： derivation.md は、人が読める推論記録です（各選択を行った理由、会話中の手がかり、確信度など）。derivation-manifest.md は、機械可読な運用マニフェストです（選択内容）。スキルはマニフェストを読み取ることで、推論の文章全体を解析せずに語彙をすばやく参照できます。

このファイルを更新するユーザー：

• /setup が生成します
• /reseed が再導出後に再生成します
• /architect が承認された変更の実装時に更新します
• /add-domain が新しいドメイン語彙を追加します

---

Step 8: _schema ブロックを含むテンプレート

スキーマレベル、語彙の対応付け、ドメイン固有のフィールド要件を確認するため、ops/derivation.md を再読します。

templates/ にドメイン固有のテンプレートを作成します。

必ず作成するもの：

• 主ノートのテンプレート（ドメイン名を使用：claim-note.md、reflection-note.md、decision-note.md など）
• MOC テンプレート（ドメイン名を使用：topic-map.md、theme.md、decision-register.md など）

条件に応じて作成するもの：

• ソース記録テンプレート（処理の深さが中程度以上の場合）
• 観察テンプレート（自己進化が有効な場合。常に作成）

各テンプレートには、必須フィールド、任意フィールド、列挙値、制約を定義する _schema ブロックを必ず含めます。スキーマの唯一の信頼できる情報源はテンプレートです。

テンプレートの構造：

---
_schema:
  entity_type: "[domain]-note"
  applies_to: "[domain:notes]/*.md"
  required:
    - description
    - topics
  optional:
    - [domain-specific fields based on schema density]
  enums:
    type:
      - [domain-relevant types]
  constraints:
    description:
      max_length: 200
      format: "One sentence adding context beyond the title"
    topics:
      format: "Array of wiki links"

# Template fields
description: ""
topics: []
[domain fields with defaults]
---

# {prose-as-title}

{Content}

---

Relevant Notes:
- [[related note]] -- relationship context

Topics:
- [[relevant-moc]]

テンプレートに語彙変換を適用します。コメント内のフィールドラベルと値の例にはドメイン語彙を使用します。YAML のフィールド名は構造を表す名称（description、topics など）のままにします。

---

ステップ 9：スキル（用語変換済み、完全なセット）

処理レベル、プラットフォーム、用語のマッピング、スキル一覧を確認するため、ops/derivation.md を再度読み込んでください。

検出されたプラットフォーム向けのスキルをすべて生成してください。すべての Vault には、初日から完全なスキルセットが含まれます。完全自動化がデフォルトです。ユーザーは機能を減らすことはできますが、増やす必要はありません。

スキルのソーステンプレートは ${CLAUDE_PLUGIN_ROOT}/skill-sources/ にあります。 各サブディレクトリには SKILL.md テンプレートが含まれており、これを読み込み、用語を変換して、ユーザーのスキルディレクトリに書き込む必要があります。

インストールする 16 個のスキルソース：

ソースディレクトリ	スキル名	カテゴリ
${CLAUDE_PLUGIN_ROOT}/skill-sources/reduce/	reduce	Processing
${CLAUDE_PLUGIN_ROOT}/skill-sources/reflect/	reflect	Processing
${CLAUDE_PLUGIN_ROOT}/skill-sources/reweave/	reweave	Processing
${CLAUDE_PLUGIN_ROOT}/skill-sources/verify/	verify	Processing
${CLAUDE_PLUGIN_ROOT}/skill-sources/validate/	validate	Processing
${CLAUDE_PLUGIN_ROOT}/skill-sources/seed/	seed	Orchestration
${CLAUDE_PLUGIN_ROOT}/skill-sources/ralph/	ralph	Orchestration
${CLAUDE_PLUGIN_ROOT}/skill-sources/pipeline/	pipeline	Orchestration
${CLAUDE_PLUGIN_ROOT}/skill-sources/tasks/	tasks	Orchestration
${CLAUDE_PLUGIN_ROOT}/skill-sources/stats/	stats	Navigation
${CLAUDE_PLUGIN_ROOT}/skill-sources/graph/	graph	Navigation
${CLAUDE_PLUGIN_ROOT}/skill-sources/next/	next	Navigation
${CLAUDE_PLUGIN_ROOT}/skill-sources/learn/	learn	Growth
${CLAUDE_PLUGIN_ROOT}/skill-sources/remember/	remember	Growth
${CLAUDE_PLUGIN_ROOT}/skill-sources/rethink/	rethink	Evolution
${CLAUDE_PLUGIN_ROOT}/skill-sources/refactor/	refactor	Evolution

各スキルについて：

1. ${CLAUDE_PLUGIN_ROOT}/skill-sources/[name]/SKILL.md を読み込みます
2. 用語変換を適用します。ops/derivation.md の用語マッピングを使用して、内部参照をすべて名称変更し、更新します
3. スキルのメタデータを調整します（呼び出しごとに新しいコンテキストを使用するため、context: fork を設定します）
4. 変換した SKILL.md をユーザーのスキルディレクトリに書き込みます

Claude Code の場合： .claude/skills/[domain-skill-name]/SKILL.md に書き込みます

重要： スキルをゼロから生成したり、内容を即興で作成したりしないでください。ソーステンプレートを読み込み、変換してください。テンプレートには品質ゲート、手順を省略しないための指示、引き継ぎ形式が含まれており、これらを維持する必要があります。

生成するすべてのスキルには、次の内容を含める必要があります：

• 品質が特に重要な手順に対する、手順を省略しないための指示
• 明確な合格／不合格基準を備えた品質ゲート
• オーケストレーション実行用の引き継ぎブロック形式
• ドメインに適した用語を一貫して使用すること

スキルの検出可能性プロトコル

プラットフォームの制限： Claude Code のスキルインデックスはセッション中に更新されません。/setup 中に作成したスキルは、ユーザーが Claude Code を再起動するまで検出できません。

すべてのスキルファイルを作成した後：

1. ユーザーに通知します： 「[N] 個のスキルを生成しました。Claude Code を再起動して有効にしてください。」と表示します。
2. コンテキストファイルに追加します： 生成したすべてのスキルについて、ドメインに適した名称と作成日時を記載した「Recently Created Skills (Pending Activation)」セクションを追加します。

## Recently Created Skills (Pending Activation)

These skills were created during initialization. Restart Claude Code to activate them.
- /[domain:reduce] -- Extract insights from source material (created [timestamp])
- /[domain:reflect] -- Find connections between [domain:notes] (created [timestamp])
...

3. SessionStart フックが有効化を検出します： session-orient.sh フックはこのセクションを確認します。スキルが読み込まれたことが確認されたら（スキルインデックスに表示されたら）、このセクションをコンテキストファイルから削除できます。
4. フェーズ 6 の案内： スキルを作成した場合、フェーズ 6 の出力に「今すぐ Claude Code を再起動してすべてのスキルを有効にし、続けて /[domain:help] を試して利用可能な機能を確認してください。」と含めます。

---

ステップ 10：フック（プラットフォームに応じて設定）

自動化レベル、プラットフォームのティア、用語のマッピングを確認するため、ops/derivation.md を再度読み込んでください。

追加型フックマージプロトコル

生成されたフックで既存のユーザーフックを上書きしてはいけません。フックを書き込む前に、次の手順を実行します。

1. 既存の .claude/settings.json を読み込みます（存在する場合）
2. 各イベントタイプ（hooks.SessionStart、hooks.PostToolUse、hooks.Stop など）の既存のフックマッチャーグループを解析します
3. イベント配列に新しいマッチャーグループを追加します。既存のエントリは置き換えないでください
4. 同じイベントに同じ command パスを持つマッチャーグループがすでに存在する場合は、スキップします（出力で警告し、上書きしないでください）
5. マージした結果を .claude/settings.json に書き戻します

検証基準： フックの生成後も、事前に存在していたすべてのフックが維持され、機能していること。

セッション永続化アーキテクチャ

セッションの永続化は、/clear やセッションの再起動をまたいだ継続性を保つうえで重要です。

セッションデータのレイアウト：

ops/
├── sessions/
│   ├── current.json          # Active session state (updated by hooks)
│   └── YYYYMMDD-HHMMSS.json  # Archived session records
├── goals.md                  # Persistent working memory (survives /clear)
└── config.yaml               # Live configuration

current.json は、session_id、start_time、notes_created（配列）、notes_modified（配列）、discoveries（配列）、last_activity タイムスタンプを記録します。

セッション ID の導出： CLAUDE_CONVERSATION_ID 環境変数（Claude Code のフック環境で利用可能）を使用します。フォールバックとしてタイムスタンプ $(date +%Y%m%d-%H%M%S) を使用します。

/clear 時のセッション復元： ユーザーが /clear を実行すると、新しい会話で SessionStart が発火します。フックは既存のセッションデータ（goals.md、ops/ の状態）を検出し、すべてを読み直して、コンテキストがリセットされた後も継続性を保ちます。

フルフックスイート（すべてのシステム向けに生成）

Claude Code では、.claude/settings.json に追加します（追加型マージを使用）。

フックの形式： Claude Code は、ネストされたマッチャーグループ構造を使用します。各イベントタイプにはマッチャーグループの配列が含まれ、各グループには、フックが発火するタイミングをフィルタリングする省略可能な matcher（正規表現文字列）と、ハンドラーオブジェクトの hooks 配列が含まれます。SessionStart や Stop などのイベントではマッチャーは不要なため、このフィールドを省略します。PostToolUse などのツールイベントでは、ツール名をマッチャーとして使用します（例："Write"、"Edit|Write"）。タイムアウトの単位は秒です。

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/session-orient.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/validate-note.sh"
          },
          {
            "type": "command",
            "command": "bash .claude/hooks/auto-commit.sh",
            "async": true
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/session-capture.sh"
          }
        ]
      }
    ]
  }
}

重要： 旧式のフラット形式（マッチャーレベルでの "type": "command"）は Claude Code に拒否されます。各イベントでは、ネストされた構造を使用する必要があります："EventName": [{ "matcher": "...", "hooks": [{ "type": "command", "command": "..." }] }]。

4 つすべてのフックスクリプトを生成します：session-orient.sh、session-capture.sh、validate-note.sh、auto-commit.sh。

---

ステップ 11：ハブ MOC

語彙のマッピングとユースケースのコンテキストについて、ops/derivation.md を再読してください。

[domain:notes]/index.md にボルトのエントリーポイントを作成します。

---
description: Entry point to the knowledge system -- start here to navigate
type: moc
---

# index

Welcome to your [domain] system.

## [domain:Topics]
[Links to self/ MOCs and any domain-specific topic MOCs that are relevant]
- [[identity]] -- who the agent is and how it approaches work
- [[methodology]] -- how the agent processes and connects knowledge
- [[goals]] -- current active threads

## Getting Started
1. Read self/identity.md to understand your purpose
2. Capture your first [domain:note] in [domain:notes]/
3. Connect it to this hub

---

ステップ 12：セマンティック検索のセットアップ（条件付き）

semantic-search 機能が有効な場合のみ（linking に implicit が含まれる場合）。

1. qmd がインストールされているか確認します：which qmd
2. インストールされている場合：
   • 生成されたボルトのルートディレクトリで qmd init を実行します
   • {vocabulary.notes_collection} 用の qmd コレクションを設定または更新し、生成されたノートディレクトリを参照するようにします
   • ボルトのルートディレクトリにこの qmd MCP サーバーの契約を含む .mcp.json を作成またはマージします：
     • {"mcpServers":{"qmd":{"command":"qmd","args":["mcp"],"autoapprove":["mcp__qmd__search","mcp__qmd__vector_search","mcp__qmd__deep_search","mcp__qmd__get","mcp__qmd__multi_get","mcp__qmd__status"]}}}
   • qmd update && qmd embed を実行して初期インデックスを構築します
3. インストールされていない場合：
   • qmd をインストールするようユーザーに案内する「次のステップ」セクションをフェーズ 6 の概要に追加します
   • 具体的なコマンドを記載します：
     • npm install -g @tobilu/qmd（または bun install -g @tobilu/qmd）
     • qmd init
     • qmd collection add . --name {vocabulary.notes_collection} --mask "**/*.md"
     • qmd update && qmd embed
   • qmd のインストール後に確実に有効化されるよう、セットアップの出力に autoapprove エントリを含む .mcp.json の qmd MCP 契約を記載します

---

ステップ 13：グラフクエリスクリプト（テンプレートスキーマから派生）

ops/derivation.md と、スキーマフィールド用に生成されたテンプレートを再度読みます。

テンプレートの作成後（ステップ 8）、_schema ブロックを読み取り、ドメインに合わせた分析スクリプトを ops/queries/（Claude Code の場合は scripts/queries/）に生成します。

生成アルゴリズム：

1. 生成されたテンプレートから、すべての _schema.required フィールドと _schema.optional フィールドを読み取ります
2. クエリ可能なディメンションを特定します（列挙値を持つフィールド、日付フィールド、Wiki リンクを含む配列フィールド）
3. 意味のある 2 フィールドの組み合わせごとに、ripgrep ベースのクエリスクリプトを生成します：
   • 相互参照クエリ -- 一方のフィールド値が同じで、もう一方のフィールド値が異なるノート
   • 時間クエリ -- 指定したステータスで N 日以上経過した項目
   • 密度クエリ -- エントリ数の少ないフィールド（ギャップの検出）
   • バックリンククエリ -- 特定のエンティティを参照しているもの
4. 各スクリプトに内容が分かる名前を付けます

ドメインに適したスクリプトを 3～5 個生成します。例：

ドメイン	生成するクエリ
セラピー	trigger-mood-correlation.sh、recurring-triggers.sh、stale-patterns.sh
研究	cross-methodology.sh、low-confidence-candidates.sh、source-diversity.sh
人間関係	neglected-contacts.sh、topic-overlap.sh
PM	overdue-items.sh、owner-workload.sh、priority-distribution.sh

コンテキストファイルに探索セクションを追加し、利用できるクエリ、その実行タイミング、得られる洞察を記載します。

---

ステップ 14：ops/reminders.md

必ず生成します。 形式を示すヘッダーを含む空のリマインダーファイルを作成します：

# Reminders

---

ステップ 15：Vault マーカー

Vault のルートに .arscontexta を作成します。このマーカーファイルは、ディレクトリが Ars Contexta の Vault であることを示します（フックはこのファイルが存在する場合にのみ実行されます）。また、フック設定ファイルも兼ねています。

# Ars Contexta vault marker + config
# This file identifies the directory as an Ars Contexta vault.
# Do not delete — hooks only run when this file exists.

git: true
session_capture: true

キーとデフォルト値：

• git: true — 書き込み時に自動コミットします（auto-commit.sh）
• session_capture: true — セッション開始時にセッション JSON を取得します（session-orient.sh）

省略されたキーは true がデフォルトになるため、最小限のマーカーファイル（空のファイルでも可）でもデフォルトの動作がすべて維持されます。

---

ステップ 16：Git の初期化

git init
git add -A
git commit -m "Initial vault generation by Ars Contexta"

すでに Git が初期化されている場合（既存のリポジトリの場合）は、git init をスキップし、生成したファイルをコミットするだけにします。

---

フェーズ 6：検証と概要

カーネル検証

生成されたシステムに対して、15 個のプリミティブチェックをすべて実行します。利用可能であれば ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh を使用してください。そうでない場合は手動で検証します：

1. markdown-yaml -- すべての .md ファイルに有効な YAML frontmatter があるか？（>95% のしきい値）
2. wiki-links -- すべての wiki リンクが既存のファイルに解決されるか？（>90% のしきい値）
3. moc-hierarchy -- 少なくとも 3 つの MOC が存在し、すべてのノートが少なくとも 1 つの MOC に含まれているか？
4. tree-injection -- セッション開始手順がファイル構造を読み込むか？（フックまたはコンテキストファイルの指示）
5. description-field -- すべてのノートにタイトルとは異なる description フィールドがあるか？（>95%）
6. topics-footer -- すべての非 MOC ノートに topics フィールドが存在するか？（>95%）
7. schema-enforcement -- テンプレートが単一の信頼できる情報源として存在し、検証メカニズムが存在するか？
8. semantic-search -- 将来の有効化に向けて設定または文書化されているか？
9. self-space -- self/ が identity.md、methodology.md、goals.md とともに存在するか？
10. session-rhythm -- コンテキストファイルが orient/work/persist サイクルを文書化しているか？
11. discovery-first -- コンテキストファイルに Discovery-First Design セクションが含まれ、ノートが発見しやすさに最適化されているか？
12. operational-learning-loop -- ops/observations/ と ops/tensions/ が存在し、レビュートリガーがコンテキストファイルに文書化され、/{DOMAIN:rethink} コマンドが存在するか？
13. task-stack -- ops/tasks.md が存在するか？キュー ファイル（ops/queue/queue.json）が schema_version >= 3 と maintenance_conditions セクションとともに存在するか？コンテキストファイルが session-orient フェーズで両方を参照しているか？/{DOMAIN:next} コマンドが条件調整とともに存在するか？
14. methodology-folder -- ops/methodology/ が methodology.md MOC とともに存在するか？少なくとも 1 つの derivation-rationale ノートが存在するか？コンテキストファイルがメタスキルのコンテキストとして ops/methodology/ を参照しているか？
15. session-capture -- ops/sessions/ ディレクトリが存在するか？セッション終了フック テンプレートがインストールされているか？未処理のセッションに対する条件ベースのマイニング トリガーが存在するか？

結果を報告します：各プリミティブの合否と、具体的な失敗を列挙します。

パイプライン スモーク テスト

カーネル検証の後、機能テストを実行します：

1. [domain:notes]/ にサンプルのタイトルと説明を含むテスト ノートを作成します
2. 正しいスキーマ（description、topics）を持っていることを検証します
3. ハブ MOC がそれを参照できることを検証します
4. テスト ノートを削除してクリーンアップします

スモーク テストが失敗した場合は、具体的な修正手順とともに失敗を報告します。構造検証に合格しても機能テストに失敗する vault は、準備が整っているとは言えません。

クリーンな CLI 出力

セクション 10.5 のデザイン言語に従って、クリーンなフォーマットで結果を表示します。ルーン文字、シジル、装飾的な Unicode、ASCII アートは使用しません。標準の markdown フォーマットのみを使用した、クリーンでインデントされたテキストを使用します。

ars contexta -- the art of context

  Creating your [domain] structure...
  Writing your context file...
  Installing [domain:skills]...
  Setting up templates...
  Building your first [domain:topic map]...
  Initializing version control...
  Running validation...

Your memory is ready.

• 進捗マーカー： 生成のマイルストーンにはインデントされたテキストを使用します。これらは生成中の方向性を示します。
• セクション区切り： 主要な出力セクション間には ---（標準 markdown）を使用します。

プログレッシブ機能の公開

利用可能なコマンドをユーザーの語彙で表示します。ops/derivation-manifest.md の語彙からコマンド名を解決します：

Here's what you can do:

  /arscontexta:[domain:reduce]    -- extract insights from source material
  /arscontexta:[domain:reflect]   -- find connections between your [domain:notes]
  /arscontexta:health             -- check your knowledge system
  /arscontexta:help               -- see everything available
  /arscontexta:next               -- get intelligent next-action recommendations
  /arscontexta:learn              -- research a topic and grow your graph

注：プラグイン コマンドは /arscontexta:command-name の形式を使用します。タブ補完に表示されない可能性があるため、すべてのコマンドを明示的に列挙します。スキルが生成された場合は、Claude Code の再起動が必要であることに注意してください。

初回成功の瞬間

ユーザーが最初のノートを記録できるよう案内します。ここでシステムは抽象的なものではなく、実際に使えるものになります。

プリセットが選択されている場合： ${CLAUDE_PLUGIN_ROOT}/presets/[preset]/starter/ を確認し、ドメイン固有のスターターノートを探します。最も関連性の高いスターターを種として使います。

1. ドメインに適したスターターノート（例：調査上の主張、個人的な振り返り、プロジェクトの決定事項）を提示します
2. ユーザーに尋ねます：「始めるためのスターター [domain:note] です。カスタマイズしますか？それとも、このまま保存しますか？」
3. 適切なスキーマで [domain:notes]/ にノートを作成します
4. ハブ MOC に追加します
5. ノート、追加先の MOC、入力済みのスキーマフィールドを表示します

プリセットがない場合： 自由形式で案内します：「何か記録してみましょう。アイデアを話してください。」その後、ノートを作成し、同じ結果を表示します。

これが重要な理由： 初回成功の瞬間によって、システムが機能することを実感できます。ユーザーは、自分のコンテンツが構造化され、つながり、たどれるようになるのを目にします。これにより、抽象的なアーキテクチャが具体的な価値へと変わります。

まとめ

ユーザーの語彙を使い、整った書式で提示します。

ars contexta

Your [domain] system is ready.

Configuration:
  Platform:        [Claude Code / Minimal]
  Automation: Full — all capabilities from day one
  [Key dimension highlights relevant to the user]

Created:
  [list of folders with domain names]
  [context file name]
  [templates created]
  16 skills generated (vocabulary-transformed)
  10 plugin commands available via /arscontexta:*
  [hooks configured]
  ops/derivation.md      -- the complete record of how this system was derived
  ops/derivation-manifest.md -- machine-readable config for runtime skills
  ops/methodology/       -- vault self-knowledge (query with /ask or browse directly)
  ops/config.yaml        -- edit this to adjust dimensions without re-running init

Kernel Validation: [PASS count] / 15 passed
[Any warnings to address]

IMPORTANT: Restart Claude Code now to activate skills and hooks.
  Skills and hooks take effect after restart — they are not available in the current session.

Next steps:
  1. Quit and restart Claude Code (required — skills won't work until you do)
  2. Read your CLAUDE.md -- it's your complete methodology
  3. Try /arscontexta:help to see all available commands
  4. [If qmd not installed: "Install qmd for semantic search: npm install -g @tobilu/qmd (or bun install -g @tobilu/qmd), then run qmd init, qmd update, qmd embed"]
  5. [If personality not enabled: "Run /arscontexta:architect later to tune the agent's voice"]
  6. Try /arscontexta:tutorial for a guided walkthrough

条件に応じた次のステップ

システムの状態に応じて、以下を含めます。

• qmd がインストールされておらず、semantic-search が有効な場合：npm/bun のインストール手順 + qmd init/update/embed + .mcp.json の契約
• personality が有効でない場合：vault に 50 件以上のノートが蓄積された後、今後の音声調整に /arscontexta:architect を使えることを伝えます
• kernel チェックに失敗したものがある場合：具体的な修正手順

---

品質基準（必須）

これらはすべての生成処理に適用されます。いずれも省略しないでください。

1. 生成ファイルに一貫性があり、ブロックを寄せ集めた印象がありません。 出力ではブロックの境界が見えないようにします。コンテキストファイルは、そのドメインに合わせて一から書かれたように読める必要があります。

2. 言葉遣いがユーザーのドメインに合っています。 セラピーを利用するユーザーに「主張」や「削減」は使いません。PM ユーザーに「振り返り」や「表面」は使いません。語彙の適合性は、生成されるすべてのファイルで確認します。

3. self/identity.md がテンプレート的ではなく、本物らしく感じられます。 人物設定のシートではなく、自己認識として読める必要があります。

4. 生成されるファイルは、すぐに役立ちます。 プレースホルダーの内容を含めません。「TODO: ここに記入」のような記述も使いません。すべてのファイルが初日から役割を果たします。

5. 次元の設定には根拠があります。 導出の根拠では、ユーザーのシグナルか、研究に裏付けられたデフォルト設定のいずれかに、すべての選択を結び付けます。

6. Kernel の検証に合格します。 生成されるすべてのシステムで失敗がゼロである必要があります。検証に失敗した場合は、結果を提示する前に生成内容を修正します。

7. すべてのファイルで語彙に一貫性があります。 同じ普遍的な用語は、生成されるすべてのファイルで必ず同じドメイン用語に対応させます。頭の中で一貫性を確認します。たとえば、コンテキストファイルで「振り返り」と表現した場合、テンプレート、スキル、self/ ファイルでも「振り返り」を使います。

8. 3 つの領域の境界を明確にします。 エージェントの自己認識は self/ に、ドメイン知識は notes/ に、運用上の足場は ops/ に配置します。これらを混同しません。

9. 発見しやすさを最優先します。 すべてのノート、すべての MOC、すべてのテンプレートを、将来のエージェントによる発見に最適化します。説明の品質、MOC への所属、タイトルの組み合わせやすさが重要です。

10. パーソナリティが手法と矛盾しないようにします。 遊び心のあるエージェントでも品質ゲートを徹底します。親しみやすいエージェントでも組み合わせやすさの確認を必須とします。パーソナリティが変えるのは手法の伝え方であり、手法を徹底するかどうかではありません。