doc-create-note

name	doc-create-note
description	在 Obsidian 笔记仓库中创建一篇普通笔记的骨架（frontmatter + 一级标题，不含正文）。当用户要新建笔记、写一篇笔记、记录某个知识点、加一篇学习笔记时使用，例如「在 Spring 下写一篇 IOC 笔记」「记录一下 JVM 垃圾回收」。创建前必须先确认笔记名和明确的相对位置（放在哪个分类目录下），用户未指定位置时必须询问，绝不凭猜测创建。如果是要新建一个分类目录（目录 + 文件夹笔记），改用 doc-create-category。

创建普通笔记（骨架）

本 skill 只负责创建一篇普通笔记的骨架：frontmatter + 一级标题，到此为止。正文内容由用户后续自行整理，你不要写。

核心铁律：只建骨架，绝不写正文

骨架 = 仅以下两部分，不多一个字：

1. frontmatter：分类 按位置填好（图谱归属边，见下）；创建时间 填当前时间；其余字段保留但留空。
2. 一级标题：与文件名一致，即 # 笔记名。

违反「只建骨架」就是违反这个 skill 的本意。 笔记一旦由你塞入正文，用户后续整理时要么被迫迁就你写的角度，要么删掉重写——位置没锁死内容，但你的内容会污染他的思路。

为什么：笔记的正文是用户的理解与整理，不是你对主题的复述。用户调用本 skill 是要「占个位」，不是要你代笔。

诱惑与反驳（自检表）

动笔前若冒出下面任何念头，停下来——那是越界信号：

借口	现实
「我了解这个主题，写点内容更有用」	用户明确说内容由他自行整理；你写的角度未必是他要的
「只写一行概述/描述总行吧」	不行。骨架不含任何正文，哪怕一行
「顺手把 frontmatter 的 描述 填了」	描述 也留空，除非用户明确指定
「我查到网上的资料，整理一下填进去」	禁止。要查资料、抓网页，是另一个请求，不在本 skill 范围
「加个 TODO / 待补充 占位符显得完整」	不需要。只有标题的笔记就是合法骨架
「标题下空着太难看，补两段」	空着是对的。用户要的就是一张白纸

红旗清单——出现即停手

• 准备写 H1 以下的任何正文段落
• 想调用 WebSearch / defuddle「补充点背景」
• 想「顺便」填 描述（用户没明确要求时）
• 觉得「骨架太空，帮用户起个头」

以上全部 = 越界。只交付 frontmatter + 一级标题。

与 doc-create-category 的区别

• 本 skill 创建普通笔记（写内容的知识点笔记）的骨架。
• 若要新建一个分类（目录 + 文件夹笔记），用 doc-create-category。
• 一篇普通笔记的 分类 指向其所在目录的文件夹笔记，而不是它自己——不要混淆。

铁律：必须先拿到明确位置

• 开始写文件前，必须明确两件事：
  1. 笔记名
  2. 相对位置：放在哪个分类目录下，以相对 01-编程笔记/ 的路径表达，如「01-编程笔记/03-Java/02-服务端开发/Spring/ 下」。
• 如果用户只给了笔记名、没说放哪，停下来询问，不要根据笔记主题猜测它该归到哪个分类。用 AskUserQuestion 列出可选分类目录，或直接请用户指定。

为什么：这篇笔记归入哪个分类是用户的决策。猜错分类会导致 分类 双链、目录归属都错，而且笔记一旦放错位置，后续会被"位置锁死"。

工作流

1. 确认笔记名与位置（缺一不可，缺则询问）。笔记名用中文，简短有意义，无日期前缀。
2. 推导 分类 属性：指向所在目录的文件夹笔记（= 所在目录名）。例：放在 01-编程笔记/03-Java/02-服务端开发/Spring/ 下，分类 写 - "[[Spring]]"。
3. 填充 frontmatter：分类 填好；创建时间 填当前时间；关联笔记/描述/排序/分组 保留但留空——除非用户明确指定，否则不要替用户决定。
4. 只写一级标题：首行且唯一正文行 = 与文件名一致的 # 笔记名。
5. 创建文件到指定位置。到此为止，不写任何正文。

骨架模版

---
分类:          # 指向所在目录的文件夹笔记，如 - "[[Spring]]"
关联笔记:
描述:
排序:
分组:
创建时间: 2026年06月25日
---
# 笔记名

• 注意：模版在 # 笔记名 之后就是文件结尾，没有任何正文段落、占位符或 TODO。
• 时间填当前时间，不要回填历史。格式统一为中文：创建时间写 YYYY年MM月DD日（如 2026年06月25日）。
• frontmatter 字段未用到可留空，但不要删除字段，保持结构一致。

为什么填 分类：图谱归属边（必读）

本仓库的笔记组织是三层各司其职，不要混用：

• 物理归属 = 目录路径（树轴）。笔记放在哪个目录就属于哪个分类。文件夹笔记内嵌的 分类索引.base 用 file.folder 按物理位置聚合索引——不依赖 分类 字段。
• 分类 字段 = 关系图谱的归属边。Obsidian 的关系图谱只看 wikilink、不看文件夹路径；没有 分类 双链，笔记在图谱里就是孤儿、分类树就断了。所以 分类 指向父文件夹笔记，纯粹是为了让「这篇笔记挂在哪个分类节点下」在图谱里可见。单一值，跟随目录。
• 跨主题关联 = 正文 wikilink（图轴）。一篇笔记和其它主题的语义关联，写在正文里（随手 [[xxx]]，目标不存在留红链当面包屑）；关联笔记 字段仅在需要被 Base 显式查询时才填。

一句话：路径管"放哪"、分类 管"图谱里挂哪"、正文双链管"和谁有关系"。三者都用，职责不重叠——分类 不是路径的冗余复述，而是把路径信息"翻译"成图谱能识别的边。

常见错误

• 写了正文：最常见、最严重的错误。骨架不含正文，哪怕用户给的主题你很熟。
• 自填 描述/关联笔记：这两个字段反映用户的知识组织意图，由用户后续补，不要臆造。
• 猜分类位置：用户没指定位置就停下来问，不要按主题猜。
• 混淆普通笔记与文件夹笔记：本 skill 不创建目录、不创建文件夹笔记。
• 不填 分类：会让笔记在关系图谱里变成孤儿、分类树断开。分类 必须按位置填好。