init-workspace

init-workspace

通过一轮简短的需求澄清，接着使用内容丰富、独立完整的模板，或以相同风格定制脚手架，搭建一个开箱即用、以笔记为中心的知识项目。每个结果都包含文件夹树，以及一份记录布局并将工作引导至合适技能的 AGENTS.md。当所选模板或需求确认结果表明有必要时，还会添加工作区本地的 references/ 和 Obsidian _dashboard/（Dataview）。

适用场景

用户想要启动一个以笔记为中心的知识项目，并确定其结构和约定。当用户提出“为……设置 / 启动 / 初始化 / 搭建工作区或知识库脚手架”时，如果工作属于学习、研究、写作、学术申请、备考、演讲、理论，或其他主要产出为笔记和文档的活动，就应触发此技能。不符合这八种模板的相关请求将采用定制路径。

不适用场景

• 用户想要开展后续实际工作（批改这篇文章、写我的引言、证明这个引理）。应转交给相应领域的技能，而不是此技能。
• 项目已经存在且结构完善——此技能负责搭建脚手架，而不是重新组织。（重新运行是安全的——见 合并规则——但不会重构现有布局。）
• 若要构建实验代码库的结构（用于快速检验假设的源代码布局），请使用 research-codebase。此处的 paper 模板用于搭建写作知识库，代码结构由该技能负责。
• 用户想要软件仓库、应用程序、软件包、网站、数据管道或其他编程项目。此技能创建知识工作知识库，而不是源代码脚手架，即使用户说“启动一个项目”也一样。

模板选项

这八种模板是起点，而非固定集合——如果请求无法明确匹配其中一种，请参见下文的需求确认，了解如何搭建脚手架。

类型	用途	AGENTS.md 首先引导至的技能
learn-a-topic	从广度出发，入门陌生领域	flow-learn-new-topic
ielts	IELTS 写作练习循环（尝试 → 反馈 → 进步）	ielts-learning-planner
paper	一篇研究论文，从构思到投稿再到成果	flow-paper-lifecycle
phd-application	完整的博士 / 研究申请周期	flow-phd-application
research-notebook	持续记录研究问题、想法、证据、决策和综合分析	whiteboard-peer
study-notes	按场次进行学习循环：记录 → 扩展 → 练习，包含两个文件夹	professor-mentor-technical-teaching
talk	一场演讲 / 展示，从叙事到幻灯片	research-talk-planner
theory	理论 / 证明项目，从主张到证明再到压力测试	flow-idea-to-proof

有两种模板只提供 AGENTS.md，原因恰好相反。ielts 会创建文件夹和仪表板，但不创建 references/，因为已安装的 ielts-* 技能已经包含评分标准和反馈汇总功能。study-notes 则刻意设计成这组模板中最精简的——恰好两个文件夹，不含 references/、_dashboard/ 或 agents/——因此其 AGENTS.md 会内嵌完整方法，而不会预先创建文件，避免在追求快速记录的工作流中增加归档决策。其他六种模板都会创建各自的 references/，使工作区自成一体。

当工作按场次组织时（例如课程、系列阅读——每次学习都会产生一篇笔记和一个练习文件），请选择 study-notes；当工作按来源和子主题组织时（例如梳理陌生领域），请选择 learn-a-topic。两者都涉及学习；区分标准是组织维度。

共享 Agent 协议

有两种协议在各模板间完全相同，因此只在 templates/_shared/agents/ 下保留一份（唯一可信来源），而不在各模板中 重复。它们是一对按产物大小划分的协议： pipeline.md 适用于大型产物，note-method.md 适用于不满足该门槛的所有内容。

note-method.md — 捕捉 → 扩展 → 存储 → 查询。 每个模板的 约定都规定，小型笔记可以跳过流水线；此文件就是它们要遵循的方法，因此“跳过流水线” 不再意味着“没有方法”。它涵盖日常循环（捕捉粗略片段、在会话结束后扩展、以结构化方式存储、通过查询定位而非回忆），规定原始捕捉内容会保留在笔记中，而不会在文字读起来流畅后删除，并定义了检索约定，使前置元数据和章节标题承担实际作用，而不只是装饰。它对证据的陈述标明了认知状态——结构化格式优于非结构化格式是有证据支持的，大模型扩展仅能提升效率，其对记忆保持的影响尚未测量，而“数字内容感觉容易，所以一定学得浅”这一说法则被标记为有争议的——因此知识库不会声称超出研究结论的内容。

pipeline.md — 证据 → 草稿 → 审阅 → 验证。 一个四轮协议，在产物自身的文件内运行：流水线运行期间，证据表和待处理的审阅事项都保存在工作文件中，并在最后压缩到 Sources 部分，因此流水线不会创建按阶段拆分的辅助文件（没有 research.md/draft.md/review.md/cited.md），最终输出严格来说只有 一个文件。大小门槛将其限制在大型产物范围内；较小的内容则依据相同的 Operating contract 转由 note-method.md 处理。

两者均为通用协议，可由不同 Agent 使用：它们规定能力要求、完整性规则和输出约定，但不绑定任何特定运行环境的工具。在脚手架生成时，两者都会复制到知识库的 <vault>/agents/ 下，使工作区保持自包含且可移植。

只有完整流水线模板会包含 agents/ 文件夹，且会同时包含这两个文件：paper、theory、learn-a-topic 和 research-notebook。它们的 AGENTS.md Operating contract 会将大型研究产物导入四轮流程，将小型笔记导入笔记循环。talk、phd-application、ielts 和 study-notes 模板使用更轻量、仅强调依据的约定（无代码 + 以来源为依据 + 标记不确定性，不包含流水线），因此不会获得 agents/ 文件夹。study-notes 将所需的捕捉 → 扩展 → 存储 → 查询规则直接写入其 AGENTS.md，因为添加 agents/ 会破坏其双文件夹保证。

澄清信息

在操作菜单前，先集中询问一轮简短的澄清问题——问几项即可，不要像面试一样：

1. 要做什么，怎样才算“完成”？ 请用户描述项目及其最终交付成果（提交的论文、通过的测试、安排好的演讲、获批的申请、掌握的主题，或其他以笔记为核心的知识成果）。
2. 项目标题和目标目录。 指明当前目录的确切路径，并建议将其作为默认目录；请用户确认，或提供其他路径。用户对此项的回答即为写入确认；不要再次询问同样的确认。
3. 与典型情况相比，有哪些不同之处（如果有）？ 例如，采用综述而非单篇论文、合著或小组演讲、组合式备考计划、非研究型论证项目、多论文申请周期等——这将决定下文是原样使用、调整还是定制。如果回答是“没有不同，这是标准的 X”，也完全可以，模板会保持原样。

只进行一轮提问。如果原始请求已提供了答案，请在这一轮中列出已知信息，而不是重新询问。不要再追问超出这三项答案所能提供的细节：用户回答后，应在同一轮中完成脚手架搭建。

流程

1. 运行上述澄清式收集流程，并确定采用哪条路径：
   • 原样使用 — 描述与八种模板之一相符，且没有说明任何差异。 使用该模板，不作修改。
   • 调整 — 与某一种模板相符，但存在明确指出的差异。以该模板为基础， 只根据差异调整所需内容：在 Layout 中添加或移除文件夹，添加或精简 references/ 文件，并编辑 AGENTS.md 中的文字（标题、Layout、路由、 类型标签，以及特定路径的 Operating-contract 措辞），使其准确反映 差异。保留适用于基础模板的行为保证——非编码知识工作、以来源为依据 或不编造、明确说明不确定性、忠实汇报，以及适用时的输入检查和单文件 流水线规则、合并规则与 Obsidian 格式要求——但更新文件夹名称和 特定类型的说明，使约定与调整后的 Layout 一致。agents/note-method.md 与笔记方法参考文件必须一并保留或移除：learn-a-topic 的 study-method.md 和 research-notebook 的 note-types-and-review-rhythm.md 都将记录方法交由它处理，因此，调整后 的知识库若保留其中任一参考文件，就必须保留 agents/；若移除 agents/，则必须将这些方法写入该参考文件，而不能让它指向知识库中 不存在的文件。
   • 定制 — 七种模板都不适用。仅为这个知识库合成一套脚手架（绝不写入 本仓库的 templates/），并遵循其他模板的相同结构：根据实际回答确定 文件夹树，编写完整的 AGENTS.md，并包含相同的必需章节（标题、 Operating contract、Layout、指向适合该工作的现有技能的路由、 Obsidian 格式规则）。Operating contract 必须将工作定义为以笔记为中心、 非编码；禁止编造；要求在涉及主张时以来源为依据并标注不确定性； 仅汇报已完成的工作；并要求在运行下游技能前检查必需的输入笔记。 如果工作涉及重要的、以来源为依据的综合或研究成果，还要将 templates/_shared/agents/pipeline.md 和 templates/_shared/agents/note-method.md 都复制到 agents/，与完整 流水线模板完全相同。除非回答明确表明需要，否则不要添加 _dashboard/ 或 references/；定制脚手架应精简到符合收集结果的程度，而不是成为 第八种庞大模板。 如果收集结果仍无法明确区分两种类型，请询问用户选择哪一种，不要猜测。
2. 使用已确认的目标目录。 用户对收集项目 2 的回答即为确认。请在进度 更新中说明最终确定的路径，但不要再次请求确认。
3. 读取模板。 对于原样使用或调整，打开 templates/<type>/AGENTS.md——其 Layout 章节是权威的文件夹列表 （先以此为准，再应用任何调整）。对于定制，没有模板文件可读；请 直接根据收集结果起草 AGENTS.md 和 Layout，并参考最接近的现有模板 的结构。
4. 创建文件夹树。 创建（可能经过调整或定制的）Layout 中的所有文件夹， 并在任何初始为空的文件夹中添加 .gitkeep。
5. 复制或编写预置文件。 对于原样使用，将模板的 AGENTS.md、 references/ 和 _dashboard/ 原样复制到目标目录（参见合并规则）。 对于调整，先复制这些内容，再应用指定修改。对于定制，直接编写 AGENTS.md（以及收集结果要求的任何 references/ 或 _dashboard/）。 对于包含完整流水线约定的模板或定制脚手架（paper、theory、 learn-a-topic、research-notebook，或定制的、以来源为依据的综合／ 研究成果），还要将 templates/_shared/agents/pipeline.md 和 templates/_shared/agents/note-method.md 都复制到 <vault>/agents/， 使两套协议都随知识库一并保留。talk、phd-application、ielts、 study-notes 以及任何定制的非研究脚手架使用较精简的、仅要求以来源为 依据的约定，不创建 agents/ 文件夹。
6. 编写入口文件存根。 创建 <vault>/CLAUDE.md，内容必须恰好为一行： @AGENTS.md。这样，Claude Code 会自动加载工作约定（它会读取 CLAUDE.md 并遵循 @ 导入）；而原生读取 AGENTS.md 的 Agent （Codex 等）不会受到影响。因此，AGENTS.md 仍是唯一的事实来源， 知识库在所有运行环境中的行为也保持一致。所有路径都要执行此步骤， 包括 ielts 和定制方案。（参见合并规则——绝不能覆盖现有的 CLAUDE.md。）
7. 填写单行标题。 如果用户提供了项目名称，就用它替换 AGENTS.md 顶部的项目标题占位符；否则保留占位符。
8. 汇报。 列出已创建的内容，说明采用了哪条路径（原样使用／调整／定制） 及原因，并指出应首先运行的技能（使用上表；对于定制方案，则选择适用 的现有技能），让用户清楚下一步该做什么。

合并规则

在现有目录中重新运行是安全的：只合并，绝不覆盖。 这些规则同样适用于 直接使用、调整 或 定制 的结果。如果用户明确指出已有的脚手架 vault，只需通过信息收集确认目标，以及填补空缺所需的事实；不要重新推导或重新设计现有工作区。

• 创建缺失的文件夹；保留现有文件夹不变。
• 仅当目标位置不存在同名文件时，才写入预置或定制文件。绝不覆盖现有的 AGENTS.md、参考资料、仪表板、agents/ 文件或任何内容文件——其中可能包含用户的作品或编辑内容。
• 旧版工作流迁移（唯一例外）。 如果 <vault>/agents/ 中包含已弃用的四个角色文件（researcher.md、reviewer.md、verifier.md、writer.md），它们属于旧版分阶段设计中的预置文件，而非用户内容：请提出删除这些文件，并在原位置安装 pipeline.md 和 note-method.md，以免 vault 中出现两套相互冲突的协议。删除前须征得用户确认，并保留用户表示修改过的任何文件。
• 如果 AGENTS.md 已存在，不要替换；告知用户该工作区已有此文件，并停止对它进行任何操作。
• 如果 CLAUDE.md 已存在，不要替换——用户可能在其中添加了自己的导入或记忆。如果该文件尚未引入 AGENTS.md，请告知用户，以便他们自行添加 @AGENTS.md。

注意事项

• 模板面向 Obsidian vault（YAML frontmatter、[[wikilinks]]、_dashboard/ Dataview）。这些文件夹都是普通文件夹，因此也可以使用代码编辑器；只有仪表板特定于 Obsidian。
• 预置和生成的 Markdown 使用 软换行，不使用硬换行：每个正文段落或列表项都保持在同一物理行上，让 Obsidian 负责视觉换行。仅在新增段落或 Markdown 结构时插入物理换行，切勿仅为满足列宽而换行。
• 澄清环节有意保持简短——三个问题，一次批量提问，一轮对话——而非需求访谈。其目的是确定采用 直接使用、调整 还是 定制，并补全标题和目录，而非提取完整规格。对于明确指出七种类型之一且未说明差异的大多数请求，仍会采用 直接使用，与以往一样不做任何定制。
• 运行此技能时，绝不会写入仓库的 templates/ 目录。调整 和 定制 的输出只会写入目标 vault；扩充长期使用的模板集属于单独且有意进行的仓库变更（请参阅此仓库 CLAUDE.md 中的技能编写规范），而非此技能在为用户创建脚手架时会代为完成的事项。
• 此技能是自包含的：所有模板都位于此处的 templates/ 下。