recommend

ランタイム設定（ステップ 0 — 処理を開始する前に）

推奨動作を設定するため、以下のファイルを読み込んでください。

1. ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md — 伝統とユースケースのプリセット

   • 8 次元空間における、事前検証済みの整合性ポイント
   • カスタマイズの出発点であり、最終的な回答ではありません

2. ${CLAUDE_PLUGIN_ROOT}/reference/methodology.md — 普遍的な方法論の原則

3. ${CLAUDE_PLUGIN_ROOT}/reference/components.md — コンポーネントの設計図（切り替え可能な項目）

4. ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md — 各次元の位置と、それを裏付ける研究上の主張の対応表

5. ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md — 次元間のハードブロック、ソフト警告、連鎖効果

6. ${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md — 研究グラフのトピックナビゲーション

参照ファイルが見つからない場合は、その不足を明記し、利用可能な情報を使って続行してください。推奨の品質は段階的に低下しますが、構成は維持され、引用が少なくなります。

---

今すぐ実行

対象：$ARGUMENTS

ただちに解析してください。

• 対象が空、または質問の場合：会話モードに入り、確認の質問を 1～2 件してから推奨してください
• 対象にユースケースの説明が含まれる場合：そのまま推奨モードに進んでください
• 対象に --compare [A] [B] が含まれる場合：比較モードに入り、2 つのプリセットまたは設定を比較してください

今すぐ開始してください。 以下でワークフローを定義します。

---

基本方針

生成ではなく、助言です。

/recommend は、探索のためにあります。ユーザーはナレッジシステムを検討しています。ユースケースがある場合も、アプローチを比較している場合も、特定のパターンについて研究が何を示しているのか知りたい場合もあります。/recommend は、ファイルを作成せずに、具体的で研究に裏付けられた根拠を示して回答します。

これは、導入を決定する前の入口です。/setup はシステム全体を生成します。/recommend は、そのシステムがどのようなものになるか、そしてなぜそうなるかを概説し、ユーザーが次に進むか判断できるようにします。すべての推奨は、具体的な研究上の主張にたどれる必要があります。「X をおすすめします」だけでは不十分で、「[[claim]] を根拠として X をおすすめします」が最低限必要です。

他のスキルとの関係：

• /recommend → 助言的な概説（ファイルなし）
• /setup → システム全体の生成（すべてを作成）
• /architect → 既存システムの発展に関するアドバイス（現在の状態を読み取る）
• /refactor → 既存システムへの変更を実施（ファイルを変更）

/recommend は、既存システムがなくても利用できる唯一のスキルです。研究に基づく純粋な推論を行います。

---

フェーズ 1：制約を理解する

1a. ユーザー入力を解析する

ユーザーの説明からシグナルを抽出します。すべての言葉がシグナルです。

シグナルのカテゴリ	例	対応先
分野	「セラピーのセッション」「研究論文」「トレード日誌」	最も近いプリセット、スキーマ設計
規模	「始めたばかり」「数百件のメモ」「大規模なコーパス」	粒度、ナビゲーション階層
処理スタイル	「素早く記録」「深い分析」「両方」	処理の深さ、自動化レベル
プラットフォーム	「Obsidian」「Claude Code」「プレーンファイル」	プラットフォームの機能、リンクの種類
既存システム	「PARA を使っている」「ツェッテルカステンを使っている」「新規に始める」	伝統のプリセットを基準とする
課題	「何も見つけられない」「形式が多すぎる」「メモが古くなる」	次元の調整
目標	「主張を追跡する」「論拠を組み立てる」「個人的な振り返り」	メモの設計、スキーマの密度
運用者	「自分で維持する」「AI エージェントが実行する」「両方」	自動化、メンテナンス頻度

1b. 会話モード（入力が少ない場合）

ユーザーの説明に重要なシグナルが不足している場合は、確認の質問を最大 2 件してください。自由回答形式ではなく、選択肢を示します。

To recommend the right architecture, I need two things:

1. **What kind of knowledge?** (pick closest)
   - Research/learning — tracking claims, building arguments
   - Creative — drafts, revisions, inspiration
   - Operational — tasks, decisions, processes
   - Personal — reflections, goals, relationships
   - Mixed — multiple of the above

2. **Who operates it?**
   - Mostly you (human-maintained)
   - Mostly an AI agent
   - Both (shared operation)

質問は 2 件を超えないでください。推奨内容はいつでも改善できます。推奨を始めるのに必要な情報を得たら、提案してください。

1c. シグナルの不足

解析（および任意の質問）を行っても重要な情報が不足している場合は、妥当なデフォルトを設定し、それを明示します。

Assuming:
- Platform: Obsidian (most common for personal knowledge)
- Scale: moderate (50-200 notes in first year)
- Operator: human-primary with occasional AI assistance

These assumptions affect the recommendation. Correct any that don't match.

---

フェーズ 2：プリセットとの照合

2a. プリセットを読む

${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md を読みます。このファイルには次の内容が含まれています。

• 伝統的な手法のプリセット — Zettelkasten、PARA、Evergreen、Cornell など
• ユースケースのプリセット — 研究、創作、エンジニアリング、セラピーなど

2b. 最も近いものを見つける

各プリセットをユーザーのシグナルと照らし合わせて評価します。

基準	重み	評価方法
分野の一致度	高	プリセットが想定する分野は一致していますか？
処理スタイルの一致度	高	プリセットの処理の深さはユーザーのスタイルに合っていますか？
規模の一致度	中	プリセットはユーザーが想定する規模向けに設計されていますか？
課題への対応度	中	プリセットはユーザーが述べた摩擦要因に対処していますか？
目標との整合性	高	プリセットはユーザーが望むことを実現しやすくしていますか？

2c. 一致したプリセットを報告する

最も近いプリセットを示し、なぜ一致するのかを説明します。

Closest preset: [preset name]
Match quality: [strong/moderate/partial]

Why: [1-2 sentences explaining the match]
Adjustments needed: [what needs to change from the preset baseline]

ユーザーの説明が複数のプリセットの要素を含む場合は、その組み合わせについて説明します。

This blends two presets:
- [Preset A] for [which aspects]
- [Preset B] for [which aspects]

Starting from [Preset A] and adjusting [specific dimensions] toward [Preset B].

---

フェーズ 3：関連する研究を検索する

3a. トピックに基づく検索

${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md を使用して、ユーザーのユースケースに該当する研究トピックを特定します。クレームマップを読み、関連するトピック群を特定してください。

3b. セマンティック検索

qmd ツールを使用して、ユーザー固有の制約に当てはまる研究上の知見を検索します。

mcp__qmd__deep_search  query="[user's domain] knowledge management patterns"
mcp__qmd__vector_search  query="[user's specific concern or goal]"

フォールバックの順序：

• MCP ツール（mcp__qmd__deep_search、mcp__qmd__vector_search、mcp__qmd__search）
• qmd CLI（qmd query、qmd vsearch、qmd search）

ユーザーのシグナルに基づいて、対象を絞った検索を 2～4 件実行します。次の点に重点を置きます。

• 分野固有のパターン（研究がユーザーの分野を扱っている場合）
• 処理の方針（バッチ処理と継続処理、深い処理と軽い処理）
• 規模に関する考慮事項（システムの拡大に伴う変化）
• 課題に関する研究（ユーザーが説明した摩擦の原因）

3c. 関連する知見を読む

関連性がありそうな検索結果については、mcp__qmd__get（一括で読み取る場合は mcp__qmd__multi_get）を使ってクレームを読み、主張全体を理解します。確信を持って引用できるだけの深さを把握してください。

関連するクレームを 5～15 件集めます。すべてを引用するわけではありませんが、選択できる候補を集めておく必要があります。

---

フェーズ 4：シグナルを次元に対応付ける

4a. 次元とクレームの対応表を読む

${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md を読みます。このファイルでは、各次元の位置を、それを裏付ける研究上のクレームに対応付けています。

4b. 各項目の位置を決定する

8つの設定項目それぞれについて、推奨する位置を決定します。

粒度（Granularity） — atomic / moderate / compound

• 主な判断材料：ドメインの種類、処理スタイル、再利用の意図
• アトミック：調査、論証の構築、複数ドメインにまたがる統合
• 中程度：ほとんどのユースケース。労力と価値のバランスが取れています
• 複合的：創作、物語、連続したコンテンツ

構成（Organization） — flat / hierarchical

• 主な判断材料：規模、ナビゲーションの好み、運用者の種類
• フラット：ノートが200件未満、エージェントによる運用、Wikiリンクによるナビゲーション
• 階層型：ノートが500件を超える、人間による運用、フォルダーによるナビゲーション

リンク（Linking） — explicit / explicit+implicit

• 主な判断材料：プラットフォームの機能、規模、発見のニーズ
• 明示的のみ：シンプルなシステム、人間による保守、少量
• 明示的＋暗黙的：セマンティック検索が利用可能、エージェントによる運用、発見を重視

処理（Processing） — heavy / moderate / light

• 主な判断材料：コンテンツの種類、時間の予算、詳細な分析の価値
• 重い：調査、論証の構築、エージェントによる運用
• 中程度：混在するコンテンツ、労力のバランスを重視
• 軽い：素早い記録、大量、手順を最小限に抑える

ナビゲーション（Navigation） — 2-tier / 3-tier / 4-tier

• 主な判断材料：想定される規模、ドメインの複雑さ
• 2層：ノートが100件未満、単一ドメイン
• 3層：ノートが100～500件、複数のサブドメイン
• 4層：ノートが500件以上、複雑で複数のドメインにまたがる

保守（Maintenance） — condition-based (tight) / condition-based (lax) / manual

• 主な判断材料：運用者の種類、自動化のレベル、システムの重要度、変更頻度
• 条件ベース（厳しいしきい値）：大量、エージェントによる運用、変化の速いドメイン
• 条件ベース（緩いしきい値）：少量、安定したドメイン
• 手動：手順を最小限に抑え、必要に応じてのみ実施

スキーマ（Schema） — minimal / moderate / dense

• 主な判断材料：クエリのニーズ、処理の深さ、メタデータへの許容度
• 最小限：説明のみ、手順を最小限に抑える
• 中程度：説明＋種類＋トピック、クエリ可能
• 詳細：完全な来歴、検証、構造化クエリ

自動化（Automation） — full / convention / manual

• 主な判断材料：運用者の種類、プラットフォームの機能、信頼度
• 完全：エージェントによる運用、プラットフォームがフックに対応
• 慣例：人間とエージェントによる共同運用
• 手動：人間が主体、システムの習得中

4c. 確信度を割り当てる

シグナルの強さに基づき、各項目の確信度を割り当てます。

確信度	意味	該当する状況
高	強いシグナルが明確にこの位置を示しています	複数のシグナルが一致し、調査結果も裏付けており、反対のシグナルがない
中	不確実性はあるものの、妥当な推奨です	いくつかのシグナルがあり、調査結果も裏付けていますが、別の選択肢もわずかにあります
低	情報が限られている中での最善の推測です	シグナルが少なく、複数の位置が妥当であるため、ユーザーによる検証が必要です

---

フェーズ 5：インタラクションの制約に照らして検証する

5a. 制約を読む

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を読みます。

5b. ハードブロックを確認する

提案する8項目の設定を、すべてのハードブロックルールに照らしてテストします。ハードブロックは、必ず失敗する組み合わせです。

Example hard block:
  granularity: atomic + navigation: 2-tier
  At high volume (200+ notes), atomic granularity with only 2 tiers
  creates navigational vertigo — too many notes per MOC.

ハードブロックが発生した場合：

1. 競合している項目を特定する
2. 解決するための調整案を提示する（確信度の低い項目を変更する）
3. 調整後の設定がブロックを回避できる理由を説明する
4. 元の設定と調整後の設定の両方を提示する

5c. ソフト警告を確認する

ソフト警告ルールに照らしてテストします。ソフト警告は、補完する仕組みで対処できる摩擦点です。

Example soft warn:
  schema: dense + automation: manual
  Dense schemas require manual enforcement without automation.
  Compensating: add validation scripts triggered by condition checks.

ソフト警告が発生した場合：

1. 各警告を記載する
2. 補完する仕組みを特定する
3. 推奨内容に含める

5d. 連鎖的な影響を確認する

ユーザーのニーズに合わせて1つの項目を変更した場合、明示的に話し合われていない別の項目に影響が及ぶでしょうか？

Example cascade:
  User wants: processing: heavy
  Cascade pressure: maintenance should be condition-based (heavy processing
  generates more artifacts that need maintenance)

連鎖的な影響が検出された場合は、その項目を説明とともに推奨内容に含めます。

---

フェーズ 6：推奨内容を提示する

出力形式

--=={ recommend }==--

Use case: [1-sentence summary of what the user described]

Closest Preset: [preset name] ([strong/moderate/partial] match)
  [Why this preset, what adjustments needed]

## Recommended Configuration

| Dimension | Position | Confidence | Rationale |
|-----------|----------|------------|-----------|
| Granularity | [position] | [H/M/L] | [reason + claim reference] |
| Organization | [position] | [H/M/L] | [reason + claim reference] |
| Linking | [position] | [H/M/L] | [reason + claim reference] |
| Processing | [position] | [H/M/L] | [reason + claim reference] |
| Navigation | [position] | [H/M/L] | [reason + claim reference] |
| Maintenance | [position] | [H/M/L] | [reason + claim reference] |
| Schema | [position] | [H/M/L] | [reason + claim reference] |
| Automation | [position] | [H/M/L] | [reason + claim reference] |

{If interaction constraints fired:}
Interaction Constraints:
  [HARD BLOCK | SOFT WARN | CLEAN]: [description]
  [Resolution or compensating mechanism]

## Architecture Sketch

Folder structure:
  [proposed folder layout for their domain]

Components enabled:
  - [component] — [why, one line]
  - [component] — [why, one line]

Components skipped:
  - [component] — [why not needed]

## Schema Design

Base fields (all {vocabulary.note_plural}):
  description: [one-sentence summary]
  [domain-specific field]: [purpose]

Example {vocabulary.note} in your domain:
  ---
  description: [example for their domain]
  [field]: [example value]
  ---
  # [example title in their domain style]
  [2-3 lines showing what a note looks like]

## Processing Pattern

Capture: [how things enter the system]
Process: [how raw input becomes structured knowledge]
Connect: [how notes link to each other]
Maintain: [how the system stays healthy]

## Session Rhythm

Orient: [what to read at session start]
Work: [how to capture during active work]
Persist: [what to save at session end]

## Trade-offs

Optimizes for: [what this configuration prioritizes]
Sacrifices: [what it deprioritizes]
Reconsider when: [signals that the configuration should evolve]

## Research Backing

Key claims supporting this recommendation:
  - [claim title] — [how it applies to this recommendation]
  - [claim title] — [how it applies]
  - [claim title] — [how it applies]

Ready to build this? Run /setup to generate the full system.

次元ごとの根拠の深さ

各次元の根拠には、次の内容を含めてください。

1. シグナル — ユーザーの入力のどの部分がこの立場を示しているか
2. 調査結果 — そのユーザーの状況において、どの主張がこの立場を裏付けているか
3. 代替案 — もう一方の立場が何を意味し、なぜ適していないのか

例：

Granularity → atomic (high confidence):
  Signal: "track claims across disciplines" requires decomposing sources
  into individual assertions.
  Research: [[three capture schools converge through agent-mediated synthesis]]
  shows that agent processing recovers what atomic capture loses.
  Alternative: Moderate granularity would reduce processing effort but
  sacrifice cross-domain connection density, which is your primary goal.

---

比較モード（--compare）

--compare [A] [B] を指定して呼び出された場合：

1. ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md から両方のプリセットを読み込む
2. 横並びで比較を提示する：

--=={ recommend: compare }==--

Comparing: [Preset A] vs [Preset B]

| Dimension | [A] | [B] | Key Difference |
|-----------|-----|-----|----------------|
| Granularity | [pos] | [pos] | [what differs and why] |
| Organization | [pos] | [pos] | [what differs and why] |
| ... | ... | ... | ... |

Where [A] wins:
  - [scenario where A is better, with research reason]

Where [B] wins:
  - [scenario where B is better, with research reason]

For your use case: [recommendation of which to start from, if user
provided enough context]

---

品質基準

すべての推奨事項に必須の要件

1. 調査結果に基づく — 主張への参照なしに「X を推奨します」と述べないでください。特定の側面を扱う調査結果がない場合は、「これを扱う具体的な調査結果はありません。一般的な原則に基づいて推奨します」と伝えてください。

2. 確信度を正直に伝える — 確信度が低い推奨事項も、明示すれば有用です。「規模が不明確なので、ナビゲーションの階層については確信が持てません」と伝えるほうが、根拠なく断定するより適切です。

3. シンプルさを尊重する — まずはシンプルな設定を標準としてください。複雑さは後からいつでも追加できます。実用上必要な最小限の設定を推奨し、成長に応じて追加できる内容を示してください。

4. 過剰設計を避ける — ユーザーが求めていない機能を推奨しないでください。シンプルな日記を求めているユーザーに、4 階層のナビゲーションや複雑なスキーマを勧めないでください。システムを実際のニーズに合わせてください。

5. トレードオフを示す — どの立場にもコストがあります。ユーザーが情報に基づいて選択できるよう、それを明確にしてください。

アンチパターン

• すべてを最大限にするよう推奨する（すべての次元で最高レベルの複雑さを選ぶ）
• 制約マップを読まずに推奨する（無効な組み合わせを提示する）
• 2 つを超える確認質問をする（分析による麻痺を招く）
• ファイルを生成する（これは /recommend ではなく /setup の役割です）
• ユーザーが明示した問題点を無視する
• 強力な調査上の根拠なしに、ユーザーが明示した好みに反する推奨をする

---

エッジケース

ユーザーが既存のシステムについて説明する場合

ユーザーがすでにシステムを使っており、その改善について助言を求めている場合：

You already have a system. /recommend designs new systems from scratch.

For evolution advice on existing systems, run /architect — it reads your
current configuration and recommends evidence-based changes.

If you want to compare your current setup against the research-optimal
configuration, I can do that here. Want me to?

はいと答えた場合は、比較に進みます。現在の設定と、調査結果が示す設定を比較してください。

ユーザーがナレッジシステムの対象外の内容について説明する場合

リクエストがナレッジシステムに関するものでない場合（例：「アプリ用のデータベースを推奨してください」）：

/recommend is designed for knowledge system architecture — personal or
agent-operated systems for capturing, organizing, and retrieving knowledge.

Your request sounds more like [what it sounds like]. I can help with
that directly, but /recommend's research backing is specific to knowledge
management patterns.

一致するプリセットがない場合

妥当な候補となるプリセットがない場合：

No existing preset closely matches your use case. Building a custom
configuration from first principles.

Starting from: [methodology.md universal principles]
Domain signals: [what was extracted]

プリセットを基準とせずに、フェーズ 4（次元のマッピング）に進みます。プリセットが判断の基盤となるはずだった次元については、確信度が低いことを伝えてください。

ユーザーのシグナルが矛盾する場合

シグナルが相反する場合（例：「深い分析を求めているが、形式ばった手順は嫌い」）：

1. 矛盾を明示する
2. この対立について調査結果が何を示しているかを説明する
3. 対立を最もよく解消する立場を推奨する
4. トレードオフを明確に伝える

Tension detected: You want deep processing (heavy) but minimal ceremony
(light schema, manual automation). Research shows these create friction
because deep processing generates metadata that light schemas can't capture.

Resolution: Processing → moderate, Schema → moderate
  This gives meaningful analysis without overwhelming ceremony.
  You can increase processing depth later if you want deeper extraction.

ユーザーが「何が最適ですか？」と尋ねる場合

普遍的な最適解はありません。制約について確認してください：

"Best" depends on what you're optimizing for. A research system and
a personal journal need fundamentally different architectures.

Tell me:
- What kind of knowledge are you working with?
- What's your biggest frustration with your current approach?

That gives me enough to recommend something specific.