运行时配置（步骤 0 — 在任何处理之前）

阅读这些文件以配置推荐行为：

${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md — 传统和用例预设
- 8维空间中的预先验证的一致性点
- 自定义的起点，不是最终答案
${CLAUDE_PLUGIN_ROOT}/reference/methodology.md — 通用方法论原则
${CLAUDE_PLUGIN_ROOT}/reference/components.md — 组件蓝图（可以切换的内容）
${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md — 将每个维度位置映射到支持研究声明
${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md — 维度之间的硬性阻止、软性警告、级联效应
${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md — 研究图的话题导航

如果缺少任何参考文件，记录缺口但继续使用可用信息。推荐可以优雅地降级 — 引用更少，结构相同。

立即执行

目标：$ARGUMENTS

立即解析：

如果目标为空或是一个疑问：进入对话模式 — 询问1-2个澄清问题，然后推荐
如果目标包含用例描述：直接进行推荐模式
如果目标包含--compare [A] [B]：进入比较模式 — 比较两个预设或配置

现在开始。 下面的定义工作流程。

哲学

顾问式，非生成式。

/recommend 存在是为了探索。用户正在考虑一个知识系统 — 也许他们有一个用例，也许他们在比较方法，也许他们好奇研究对于特定模式说了什么。/recommend 用具体、研究支持的理由回答，而不是创建任何文件。

这是承诺前的入口点。/setup 生成一个完整的系统。/recommend 草图那个系统会是什么样子以及为什么，让用户可以决定是否继续。每个推荐都追溯到具体的研究声明。“我推荐 X” 是不够的 — “我推荐 X 因为 [[claim]]” 是最低要求。

与其他技能的关系：

/recommend → 顾问草图（无文件）
/setup → 完整系统生成（创建一切）
/architect → 现有系统的进化建议（读取当前状态）
/refactor → 对现有系统实施更改（修改文件）

/recommend 是唯一一个不需要现有系统就能工作的技能。它是纯粹的研究推理。

第一阶段：理解约束

1a. 解析用户输入

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

信号类别	示例	映射到
领域	“治疗会话”, “研究论文”, “交易日志”	最接近的预设，模式设计
规模	“刚开始”, “数百个笔记”, “庞大语料库”	粒度，导航层级
处理风格	“快速捕获”, “深度分析”, “两者”	处理深度，自动化水平
平台	“Obsidian”, “Claude Code”, “普通文件”	平台能力，链接类型
现有系统	“我使用PARA”, “我有Zettelkasten”, “从头开始”	传统预设基线
痛点	“找不到任何东西”, “太多仪式”, “笔记过时”	维度调整
目标	“跟踪声明”, “构建论点”, “个人反思”	笔记设计，模式密度
操作员	“我将维护它”, “AI代理运行它”, “两者”	自动化，维护频率

1b. 对话模式（当输入不足时）

如果用户的描述缺少关键信号，询问最多2个澄清问题。将它们构建为选择，而不是开放式的：

为了推荐正确的架构，我需要两件事：

1. **什么样的知识？**（选择最接近的）
   - 研究/学习 — 跟踪声明，构建论点
   - 创意 — 草稿，修订，灵感
   - 操作 — 任务，决策，流程
   - 个人 — 反思，目标，关系
   - 混合 — 以上多个

2. **谁操作它？**
   - 大部分是你（人类维护）
   - 大部分是AI代理
   - 两者（共享操作）

不要问超过2个问题。推荐总是可以细化的。得到足够的开始，然后推荐。

1c. 信号不足

如果解析（和可选问题）后你仍然缺乏关键信息，做出合理的默认并声明它们：

假设：
- 平台：Obsidian（个人知识最常见）
- 规模：中等（第一年50-200个笔记）
- 操作员：以人为主，偶尔AI辅助

这些假设影响推荐。如果有任何不匹配，请纠正。

第二阶段：匹配预设

2a. 阅读预设

阅读 ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md。此文件包含：

传统预设 — Zettelkasten, PARA, Evergreen, Cornell等。
用例预设 — 研究，创意写作，工程，治疗等。

2b. 找到最接近的匹配

对用户的信号对每个预设进行评分：

标准	权重	如何评分
领域匹配	高	预设的预期领域是否匹配？
处理风格匹配	高	预设的处理深度是否与用户的风格匹配？
规模匹配	中等	预设是否为用户预期的规模设计？
痛点覆盖	中等	预设是否解决了用户声明的摩擦？
目标一致性	高	预设是否优化了用户想要的东西？

2c. 报告匹配

声明最接近的预设并解释匹配：

最接近的预设：[预设名称]
匹配质量：[强/中等/部分]

为什么：[1-2句话解释匹配]
需要调整的内容：[需要从预设基线改变什么]

如果用户的描述混合了多个预设，解释混合：

这混合了两个预设：
- [预设A]用于[哪些方面]
- [预设B]用于[哪些方面]

从[预设A]开始，调整[具体维度]朝向[预设B]。

第三阶段：搜索相关研究

3a. 基于主题的搜索

使用 ${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md 确定哪个研究主题适用于用户的用例。阅读声明图并确定相关主题群集。

3b. 语义搜索

使用 qmd 工具找到适用于用户具体约束的研究声明：

mcp__qmd__deep_search  query="[用户的领域]知识管理模式"
mcp__qmd__vector_search  query="[用户的具体关注或目标]"

回退链：

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个相关声明。你不会引用它们全部 — 但你需要一个池来抽取。

第四阶段：将信号映射到维度

4a. 阅读维度声明图

阅读 ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md。此图将每个维度位置映射到支持它的研究声明。

4b. 确定每个位置

对于8个配置维度中的每一个，确定推荐的位置：

粒度 — 原子/中等/复合

关键信号：领域类型，处理风格，重用意图
原子：研究，论证构建，跨领域综合
中等：大多数用例，平衡努力与价值
复合：创意写作，叙事，顺序内容

组织 — 平坦/层次

关键信号：规模，导航偏好，操作员类型
平坦：<200笔记，代理操作，维基链接导航
层次：>500笔记，人类操作，文件夹导航

链接 — 显式/显式+隐式

关键信号：平台能力，规模，发现需求
仅显式：简单系统，人类维护，低容量
显式+隐式：语义搜索可用，代理操作，发现重点

处理 — 重/中等/轻

关键信号：内容类型，时间预算，深度分析的价值
重：研究，论证构建，代理操作
中等：混合内容，平衡努力
轻：快速捕获，高容量，低仪式

导航 — 2层/3层/4层

关键信号：预期规模，领域复杂性
2层：<100笔记，单一领域
3层：100-500笔记，多个子领域
4层：500+笔记，复杂的多领域

维护 — 基于条件（紧密）/基于条件（宽松）/手动

关键信号：操作员类型，自动化水平，系统关键性，变化率
基于条件（紧密阈值）：高容量，代理操作，快速变化领域
基于条件（宽松阈值）：低容量，稳定领域
手动：最小仪式，按需

模式 — 最小/中等/密集

关键信号：查询需求，处理深度，元数据容忍度
最小：仅描述，低仪式
中等：描述+类型+主题，可查询
密集：完整出处，验证，结构化查询

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

关键信号：操作员类型，平台能力，信任水平
全自动：代理操作，平台支持钩子
约定：共享人类-代理操作
手动：以人为主，学习系统

4c. 分配信心

对于每个维度，根据信号强度分配信心：

信心	含义	何时
高	强烈的信号明确指向这个位置	多个信号汇聚，研究支持，无反信号
中等	合理的推荐，有一些不确定性	一些信号存在，研究支持，存在次要替代品
低	根据有限信息做出的最佳猜测	信号少，多个有效位置，用户应该验证

第五阶段：验证交互约束

5a. 阅读约束

阅读 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md。

5b. 检查硬性阻止

测试提出的8维配置是否符合所有硬性阻止规则。硬性阻止是会失败的组合：

示例硬性阻止：
 粒度：原子 + 导航：2层
  在高容量（200+笔记）时，原子粒度只有2层
  创建导航眩晕 —— 每个MOC的笔记太多。

如果硬性阻止触发：

确定哪些维度冲突
提出调整以解决（更改信心较低的维度）
解释调整后的配置如何避免阻止
呈现原始和调整后的配置

5c. 检查软性警告

测试是否符合软性警告规则。软性警告是摩擦点，有补偿机制：

示例软性警告：
  模式：密集 + 自动化：手动
  密集模式需要手动执行，没有自动化。
  补偿：添加由条件检查触发的验证脚本。

如果软性警告触发：

记录每个警告
确定补偿机制
包括在推荐输出中

5d. 检查级联效应

更改一个维度以匹配用户的需求，是否会对另一个未明确讨论的维度产生压力？

示例级联：
  用户想要：处理：重
  级联压力：维护应该是基于条件的（重处理
  产生更多需要维护的工件）

如果检测到级联效应，将级联维度包括在推荐中，并解释。

第六阶段：呈现推荐

输出格式

--=={ 推荐 }==--

用例：[用户描述的1句话总结]

最接近预设：[预设名称] ([强/中等/部分]匹配)
  [为什么这个预设，需要什么调整]

## 推荐配置

| 维度 | 位置 | 信心 | 理由 |
|-----------|----------|------------|-----------|
| 粒度 | [位置] | [H/M/L] | [原因+声明参考] |
| 组织 | [位置] | [H/M/L] | [原因+声明参考] |
| 链接 | [位置] | [H/M/L] | [原因+声明参考] |
| 处理 | [位置] | [H/M/L] | [原因+声明参考] |
| 导航 | [位置] | [H/M/L] | [原因+声明参考] |
| 维护 | [位置] | [H/M/L] | [原因+声明参考] |
| 模式 | [位置] | [H/M/L] | [原因+声明参考] |
| 自动化 | [位置] | [H/M/L] | [原因+声明参考] |

{如果交互约束触发：}
交互约束：
  [HARD BLOCK | SOFT WARN | CLEAN]：[描述]
  [解决方案或补偿机制]

## 架构草图

文件夹结构：
  [为他们领域提出的文件夹布局]

启用的组件：
  - [组件] — [为什么，一行]
  - [组件] — [为什么，一行]

跳过的组件：
  - [组件] — [为什么不需要]

## 模式设计

基础字段（所有{vocabulary.note_plural}）：
  description：[一句话总结]
  [领域特定字段]：[目的]

示例{vocabulary.note}在你们的领域：
  ---
  description：[他们领域的示例]
  [field]：[示例值]
  ---
  # [他们领域风格的示例标题]
  [2-3行显示笔记的样子]

## 处理模式

捕获：[事物如何进入系统]
处理：[原始输入如何变成结构化知识]
连接：[笔记如何相互链接]
维护：[系统如何保持健康]

## 会话节奏

定位：[会话开始时阅读什么]
工作：[主动工作时如何捕获]
持久化：[会话结束时保存什么]

## 权衡

优化：[这个配置优先考虑什么]
牺牲：[它降低优先级的是什么]
重新考虑时：[配置应该演变的信号]

## 研究支持

支持这个推荐的关键声明：
  - [声明标题] — [它如何适用于这个推荐]
  - [声明标题] — [它如何适用]
  - [声明标题] — [它如何适用]

准备构建这个吗？运行/setup生成完整系统。

每个维度的理由深度

每个维度的理由应该包括：

信号 — 用户的输入中什么指向这个位置
研究 — 哪些声明支持他们上下文中的这个位置
替代品 — 其他位置意味着什么，为什么它不太适合

示例：

粒度 → 原子（高信心）：
  信号："跨学科跟踪声明"需要将来源分解成单个断言。
  研究：[[三个捕获学校通过代理介导的综合收敛]]
  显示代理处理恢复了原子捕获所失去的。
  替代品：中等粒度会减少处理努力，但牺牲跨领域连接密度，这是你的主要目标。

比较模式 (–compare)

当使用 --compare [A] [B] 调用时：

从 ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md 读取两个预设
呈现一个并排比较：

--=={ 推荐：比较 }==--

比较：[预设A] vs [预设B]

| 维度 | [A] | [B] | 关键差异 |
|-----------|-----|-----|----------------|
| 粒度 | [位置] | [位置] | [什么不同，为什么] |
| 组织 | [位置] | [位置] | [什么不同，为什么] |
| ... | ... | ... | ... |

[A]赢的地方：
  - [A更好的情景，研究理由]

[B]赢的地方：
  - [B更好的情景，研究理由]

对于你的用例：[如果用户提供了足够的上下文，推荐从哪个开始]

质量标准

每个推荐必须

追溯到研究 — 没有"我推荐X"没有声明引用。如果没有研究覆盖特定方面，就说：“没有具体研究覆盖这个；基于一般原则推荐。”
诚实关于信心 — 低信心推荐是有价值的，如果标记了。"我对你规模不清楚的导航层级不太确定"比假自信的推荐更好。
尊重简单性 — 默认更简单的配置。用户以后总是可以增加复杂性。推荐最小可行配置，然后注明他们成长时会添加什么。
避免过度工程 — 不要推荐用户没有询问的功能。如果他们想要一个简单的日志，不要推荐4层导航和密集模式。将系统与他们实际需求相匹配。
呈现权衡 — 每个位置都有成本。使它们可见，让用户做出明智的选择。

反模式

推荐最大一切（所有维度最高复杂性）
推荐不阅读约束图（产生无效组合）
询问超过2个澄清问题（分析瘫痪）
生成文件（这是/setup的工作，不是/recommend的）
忽略用户声明的痛点
没有强有力的研究理由就推荐与用户明确偏好相反的

边缘情况

用户描述现有系统

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

你已经有系统了。/recommend 设计从零开始的新系统。

对于现有系统的进化建议，运行 /architect — 它读取你的
当前配置并推荐基于证据的更改。

如果你想比较你当前的设置与研究最优配置，我可以在这里做。你想吗？

如果他们说是，继续比较：他们当前的配置与研究建议的配置。

用户描述知识系统范围之外的东西

如果请求不是关于知识系统（例如，“推荐一个数据库给我的应用”）：

/recommend 专为知识系统架构设计 — 个人或
代理操作的系统，用于捕获、组织和检索知识。

你的请求听起来更像是[它听起来像什么]。我可以直接帮助你
但是/recommend的研究支持特定于知识管理模式。

没有预设匹配

如果没有预设合理匹配：

没有现有的预设与你用例紧密匹配。从头开始构建自定义
配置。

从：[methodology.md通用原则]
领域信号：[提取了什么]

在没有预设基线的情况下进行第4阶段（维度映射）。在预设会提供基础的地方，维度的信心较低。

用户信号冲突

当信号指向相反方向时（例如，“我想要深度分析但讨厌仪式”）：

明确命名冲突
解释研究对紧张关系的看法
推荐最好解决冲突的位置
清楚地说明权衡

检测到紧张：你想要深度处理（重）但最小仪式
（轻模式，手动自动化）。研究表明这些会产生摩擦
因为深度处理产生元数据，轻模式无法捕获。

解决方案：处理 → 中等，模式 → 中等
  这给出了有意义的分析，而不会有压倒性的仪式。
  如果你以后想要更深入的提取，可以增加处理深度。

用户问"什么是最好？"

没有通用的最佳。重定向到约束：

"最好"取决于你优化什么。研究系统和
一个个人日志需要根本不同的架构。

告诉我：
- 你正在处理哪种知识？
- 你对当前方法的最大挫败是什么？

这给了我足够的推荐具体的东西。