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]：进入比较模式——比较两个预设或配置

现在开始。 下方的参考内容定义了工作流。

---

理念

提供建议，而非生成内容。

/recommend 用于探索。用户正在考虑建立一个知识系统——他们可能有一个用例，可能正在比较不同方法，也可能想了解研究对某种特定模式的看法。/recommend 会提供具体且有研究依据的分析，但不会创建任何文件。

这是用户做出决定前的入口。/setup 会生成完整系统。/recommend 会勾勒该系统的形态及其原因，让用户决定是否继续。每条推荐都能追溯到具体的研究论断。仅说“我推荐 X”远远不够——至少要说明“我推荐 X，因为 [[论断]]”。

与其他技能的关系：

• /recommend → 提供建议的草案（不创建文件）
• /setup → 生成完整系统（创建所有内容）
• /architect → 为现有系统提供演进建议（读取当前状态）
• /refactor → 对现有系统实施更改（修改文件）

只有 /recommend 无需现有系统即可使用。它完全基于研究进行推理。

---

阶段 1：了解约束条件

1a. 解析用户输入

从用户的描述中提取信号。每个词都是一个信号：

信号类别	示例	对应内容
领域	“治疗会谈”“研究论文”“交易日志”	最接近的预设、架构设计
规模	“刚起步”“数百条笔记”“大型语料库”	粒度、导航层级
处理方式	“快速记录”“深入分析”“两者兼有”	处理深度、自动化程度
平台	“Obsidian”“Claude Code”“纯文件”	平台能力、链接类型
现有系统	“我使用 PARA”“我有一个 Zettelkasten”“从头开始”	传统预设基线
痛点	“什么都找不到”“流程太繁琐”“笔记过时了”	维度调整
目标	“追踪论断”“构建论据”“个人反思”	笔记设计、架构密度
操作者	“我来维护”“由 AI Agent 运行”“两者兼有”	自动化、维护频率

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 个配置维度，分别确定建议的位置：

粒度 — 原子 / 中等 / 复合

• 关键信号：领域类型、处理方式、复用意图
• 原子：研究、论证构建、跨领域综合
• 中等：大多数用例，在投入与价值之间取得平衡
• 复合：创意写作、叙事、顺序内容

组织方式 — 扁平 / 层级

• 关键信号：规模、导航偏好、操作主体类型
• 扁平：少于 200 条笔记，由 Agent 操作，通过维基链接导航
• 层级：超过 500 条笔记，由人操作，通过文件夹导航

链接方式 — 显式 / 显式+隐式

• 关键信号：平台能力、规模、发现需求
• 仅显式：简单系统，由人维护，数量较少
• 显式+隐式：支持语义搜索，由 Agent 操作，以发现为重点

处理方式 — 深度 / 中等 / 轻量

• 关键信号：内容类型、时间预算、深度分析的价值
• 深度：研究、论证构建，由 Agent 操作
• 中等：混合内容，投入均衡
• 轻量：快速捕获、数量多、仪式感低

导航 — 2 层 / 3 层 / 4 层

• 关键信号：预期规模、领域复杂度
• 2 层：少于 100 条笔记，单一领域
• 3 层：100-500 条笔记，多个子领域
• 4 层：500 条以上笔记，复杂的多领域结构

维护方式 — 基于条件（严格） / 基于条件（宽松） / 手动

• 关键信号：操作主体类型、自动化程度、系统关键性、变化速率
• 基于条件（严格阈值）：数量多，由 Agent 操作，领域变化快
• 基于条件（宽松阈值）：数量少，领域稳定
• 手动：仪式感最低，仅按需进行

架构 — 最简 / 中等 / 完备

• 关键信号：查询需求、处理深度、对元数据的容忍度
• 最简：仅描述，仪式感低
• 中等：描述 + 类型 + 主题，可查询
• 完备：完整溯源、验证、结构化查询

自动化 — 全自动 / 约定 / 手动

• 关键信号：操作主体类型、平台能力、信任度
• 全自动：由 Agent 操作，平台支持钩子
• 约定：人和 Agent 协同操作
• 手动：以人为主，正在学习系统

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. 检查级联效应

为了满足用户需求而更改一个维度，是否会给另一个未明确讨论的维度带来调整压力？

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 个澄清问题（导致分析瘫痪）
• 生成文件（这是 /setup 的工作，不是 /recommend 的）
• 忽略用户明确提出的痛点
• 没有充分的研究依据，却建议违背用户明确偏好的方案

---

边缘情况

用户描述现有系统

如果用户已有一套系统，并希望获得改进建议：

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.