second-brain-fix

Second Brain 修复

审计发现了问题所在，并修复了一个位置，以便看清其结构。接下来会根据审计留下的发现，分批处理其余内容。

参数

本次运行传入的 findings 文件是 $audit-results，这是可选参数：

/second-brain-fix                                   nothing passed
/second-brain-fix ~/notes                           a folder to look in
/second-brain-fix ~/notes/second-brain-audit.md     the findings file itself

$audit-results 是一个 findings Markdown 文件的路径。/second-brain-audit 会将其写入 second-brain-audit.md，所以通常交给你的会是这个文件，但文件名并非约定。任何包含 findings 的 Markdown 文件都可以使用，用户指定哪个文件，就使用哪个。

先解析该参数，再做其他任何事：

你得到的内容	操作
一个文件路径	该文件就是 findings。笔记文件夹是它的父文件夹，除非该文件另行指定了其他文件夹
一个文件夹路径	在其中查找 findings，优先查找 second-brain-audit.md
没有内容，因此上面的行仍然显示为 \$audit-results	先在当前文件夹查找，再向下一层查找
一个不存在的路径	说明情况并停止。不要改为搜索，否则拼写错误会悄悄导致操作错误的文件夹
搜索时找到多个候选项	列出这些候选项及其最新的 ## Log 日期，并询问要选哪一个
搜索时找不到任何候选项	停止。请用户先运行 /second-brain-audit，因为没有可供处理的内容

没有 findings 时，绝不要从头编造一个待处理队列。一次性审计并修复，会导致批量写入没人读过的 findings。

findings 是输入。 $audit-results 既是队列，也是记录：## Current State 中每个位置对应一行带键的记录，## Log 中每次运行对应一行带日期的记录。以下所有操作都由该文件驱动，而不更新该文件的运行将无法供后续人员接手。

本技能会批量写入内容。开始前先处理好备份。

未处理好这件事之前，绝不要开始写入；也绝不要通过将笔记文件夹复制到其他位置来解决。重复的笔记文件夹会让每个问题都有第二个答案，而这正是本技能要解决的问题。

首先，检查现有情况。 在笔记文件夹中运行 git rev-parse --show-toplevel。

• 已经纳入 git 管理，无论是独立仓库还是由父级仓库跟踪。先提交或暂存所有未处理的更改，然后运行 git checkout -b second-brain-fix，并在每批处理后提交。说明你所在的仓库，因为笔记库嵌套在其他项目中很常见，用户应该知道这个分支涵盖哪些内容。

• 未纳入 git 管理。 请使用以下措辞或类似表达询问：

  你的笔记没有纳入 git 管理，因此无法撤销批次操作。要我先在这里运行 git init 吗？ 仓库只保留在你的电脑上，不会推送到任何地方，每个批次都会成为一个可回滚的检查点。

  如果用户同意：运行 git init、git add -A，创建一个基线提交，然后创建分支。绝不要添加远程仓库，也绝不要推送。

  如果用户拒绝，再问一次并接受其答复：

  明白。需要说明的是，这会一次性改写许多文件，而且无法撤销。仍要继续吗？

  用户明确答应后即可继续，不要再提此事。用户没有回应或答复含糊时，请停止。未得到答复不代表获得许可。

三类内容，三种不同任务

类别	finding 包含的内容	操作
存在矛盾	过时的说法和较新的证据	分批修复，不提问
缺乏依据	该说法，没有任何佐证	绝不要猜测。集中向用户提问一批问题
尚未转换的位置	一个没有 ## Current State / ## Log 的页面	分批转换，原文照录

中间一行最容易导致批量修复出错。根据定义，缺乏依据的说法在笔记中没有答案，因此如果让 Agent“更正这些内容”，它就会编造一个值，或悄悄删除该行。这两种做法都比保留过时的说法更糟。

要处理多少内容

询问笔记有多大，或者统计 Markdown 文件的数量，然后相应调整目标：

规模	操作
少于约 50 个文件	一次会话内全部处理。分两到三批
约 50 到 500 个文件	先处理每次都会加载的内容，然后每批处理一个文件夹，批次之间提交
500 个以上	处理每次都会加载的内容，以及有时间线的页面（随时间记录同一主题的多条条目）。其他内容永久保持原样

笔记越多，不代表要转换的内容越多。相反，这意味着只转换更小的一部分，并更加依赖写入流程，因为到了这个规模，不可能有人一直手动维护整个档案。

第 1 步：整理批次清单

读取 $audit-results。找出 ## Current State 中未标记为已修复的条目，以及审核报告提到但未逐一列出的内容。将它们分成每批约 5 到 15 个位置；如果可以，尽量将同一文件夹放在一批。

开始写入前，先向用户展示批次清单和处理顺序。排序规则始终如下：

1. 每次会话都会加载的内容。
2. Agent 最常出错的页面。
3. 有时间线的页面。
4. 其他内容一律不处理。

第 2 步：逐批处理存在矛盾的内容

对于每条发现的问题，较新的证据已经标出。因此：

• 替换 ## Current State 中过时的行。
• 将被取代的行原文不动地移到 ## Log。
• 新行使用证据的日期，而不是今天的日期。

最后一点的重要性超乎想象。给当前值标上日期，就等于声称有人在那天核实过该值。若将今天的日期标在一条根据 6 月的笔记修正的行上，就会让 6 月的事实看起来像是今天早上核实的。

完成整批处理后，再汇总一次：替换了多少行、涉及哪些文件，以及最不容易判断的三到四处。不要逐行展示差异，也不要逐行询问。

第 3 步：逐批转换这些位置

为每个页面添加这两个部分。根据审核发现的页面结构灵活处理：

## Current State


- **Retainer** (2026-08-01): $3,200/mo, renewed through February 2027
- **Main contact** (2026-05-02): Curtis Ilo

## Log


- (2026-04-30) Delivered and paid, $21,000
- (2026-06-15) Added reply drafting, retainer to $3,200/mo

单个大文件在顶部添加 ## Current State 区块，其他所有内容放在其下方，不新建文件。每日笔记新建一个文件记录当前值，日志保持不动。非 Markdown 笔记完全不转换。

这是分类，不是改写。 现有的每一行都要原封不动地放入其中一个部分，最多只能在前面加上日期。润色文字会让信息在无人察觉的情况下消失；而批量处理时，没有人会仔细阅读到能发现这一点。

如果条目没有日期，也找不到日期，不要捏造日期，也不要悄悄让条目保持原样。如果条目引用了证据，就从证据中取日期；否则在日期的位置写上 (date unknown)。裸露的条目看起来像是疏忽；(date unknown) 则明确指出缺失之处，并会在下一次审核时保留下来，供人询问。

有两类页面应保持原样，并说明原因，而不是进行转换：

• 参考清单。 打包清单、住院包清单、标准操作步骤。加粗的键和值很少，日期也不多，而且顺序本身就是内容。转换这类清单虽然能通过所有结构检查，却会毁掉它们的实用性。
• 最新状态写在正文中的页面，并且这些内容位于统领下方条目的标题之下。拆散这个部分会导致最新状态落在 ## Current State 之外，而最旧的内容反而在其中，这正是要消除的问题，却在更高一层重现。

第 4 步：无法支持的内容，集中询问一次

把它们全部收集起来，一次性列成编号清单询问。不要逐条询问，也绝不能默默处理。

每项有三种结果：

• 仍然属实：将其写入 ## Current State，并注明用户提供的日期，明确说明缺失的是证据，而不只是归档错了。
• 不再属实：用新内容替换，并将旧行原样写入 ## Log。
• 无法确定：将其从始终加载的文件中完全移除。自信地给出错误答案，比缺少答案代价更大。

如果用户没有回答，就让每一项保持原样。问题未获回答，不代表获得了许可。

留给所有者处理的任何内容，都要在原处添加注释

摘要中的问题只会触达一个人一次。那一行会留在笔记中，并被之后的每个会话读到，因此警告必须标注在那一行上，不能只写在报告里。

只要某一行因只有所有者才能解决而被保留，就在原处追加原因，同时保持其原文不变：

- **Sam Iwu**: accepted a full-time offer, starting October 2026. UNVERIFIED (fix run
  2026-09-18): no date and no source anywhere; entities/sam-iwu.md says he is still a
  contractor. Confirm or delete.

- **Ferro retainer renewal** (2026-09-12): renewed at $6,500/mo through year-end. CONFLICT
  (fix run 2026-09-18): the 2026-09-10 call set it to $12,000/mo. Nothing sources this line.
  Ask before quoting either number.

这对于比刚刚修正的那一行更新的过时行尤其重要。如果一个键写着 $12,000，日期为 10 日；另一个键写着 $6,500，日期为 12 日，那么读取该页面的 Agent 会采用日期较新的内容并回答 $6,500。因此，除非第二个键也带有警告，否则修正第一个键毫无作用。每批处理后都要明确检查这种情况：针对每个已修正的键，查看同一页面上是否还有涉及同一主题且日期更晚的键。

绝不要删除该行来解决冲突，也绝不要自行选择一个值。添加注释就是全部处理。

第 5 步：写回结果

每批处理完后，编辑 $audit-results：

• 替换每个位置的 ## Current State 行，写入其新状态。每个位置始终只写一行，绝不添加第二行。
• 记录每一行已添加注释并保留原样的内容，以便下次运行时能看出哪些事项仍在等待所有者处理，而不必重新推导。
• 向 ## Log 追加一条记录：日期、批次、替换了多少行、转换了多少个位置，以及仍未得到答复的无证据支持声明数量。

然后提交该批次。调查结果和笔记一并保存，因此即使运行中断，也能通过读取一个文件继续处理。

第 6 步：重新审计并比较

所有批次完成后，再次运行 /second-brain-audit，并将矛盾项数量与最后一条 ## Log 记录进行比较。这个数字是判断上述处理是否奏效的唯一证据。

如果数量没有明显下降，就说明这一点并解释原因，而不要把转换说成成果。重构无法触及从未有人记录的事实；如果数量保持不变，通常就是这个原因。此时需要修复的是写入流程，而不是再处理一批。

如果调查结果文件已重命名，请特别标记：audit.py 会跳过名称以 second-brain-audit 开头的文件，因此重命名后的文件会在下次扫描时被当作证据读取，并逐字引用过时声明。要么保留原名，要么将文件放在笔记文件夹之外。

永不妥协的规则

1. 不要丢失任何内容。 每一行都必须原样保留在某处。如果某一行无法归入任何位置，就让它留在原处并报告。
2. 绝不合并看起来相似的两个主题。“Acme（5 月）”和“Acme Corp 续约”可能是两件真实存在的事。重复条目只是小失误；错误合并则会毁掉信息。在批次末尾报告相似但不确定的条目，让用户决定。批量处理默认会合并，因为合并看起来像是在整理，所以必须刻意坚守这条规则。
3. 绝不编造值，也绝不为了减少条目而删除主张。 任何留给负责人处理的内容，都必须在其所在行注明原因，而不能只在总结中说明。警告只留在聊天窗口中，正是这项技能要解决的问题。
4. 绝不编辑或删除 ## Log 条目。 这些条目过时或已被取代，正是它们存在于该章节中的意义。
5. 日期代表该值已核实这一主张。 只移动而未修改的行保留其原有日期。
6. 绝不复制 notes 文件夹作为备份。 使用 Git，或者在充分了解后选择不备份。除此之外别无选择。
7. 当始终加载的内容中已没有任何矛盾时，就停止。 充满旧页面的归档是历史，不是腐朽。不存在需要转换每个页面的情况。

如果写入路径尚未更改

检查 CLAUDE.md（或 AGENTS.md，或 system prompt）是否包含审计第 7 阶段的状态／事件规则。如果没有，就在开始前添加，并说明原因：在只能追加的写入路径下修复四百行内容，大约只能管一个月。