RethinkSkill rethink

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

阅读这些文件以配置特定领域的操作：

1. ops/derivation-manifest.md — 词汇映射，领域上下文

   • 使用 vocabulary.notes 作为笔记文件夹名称
   • 使用 vocabulary.note 作为输出中的笔记类型名称
   • 使用 vocabulary.rethink 作为输出中的命令名称
   • 使用 vocabulary.topic_map 作为 MOC 引用
   • 使用 vocabulary.cmd_reflect 作为连接查找引用

2. ops/config.yaml — 阈值，处理偏好

   • self_evolution.observation_threshold: 建议重新思考之前的待处理观察数量（默认：10）
   • self_evolution.tension_threshold: 建议重新思考之前的待处理紧张关系数量（默认：5）

3. ops/methodology/ — 现有方法论笔记（阅读所有以理解当前系统自我知识）

如果这些文件不存在（预初始化调用或独立使用），则使用通用默认值。

命令名称本身会根据领域变换。派生清单将通用名称映射到领域本地语言。如果没有清单存在，使用 “rethink” 作为命令名称。

立即执行

目标：$ARGUMENTS

立即解析：

• 如果目标为空：对所有待处理的观察和紧张关系运行完整的六阶段重新思考（阶段 0 漂移检查 + 五个证据阶段）
• 如果目标是 “triage”: 仅运行第一阶段（分类和方法论更新，无模式检测）
• 如果目标是 “patterns”: 跳过分类，仅运行第三至第五阶段（分析现有证据以寻找模式）
• 如果目标是 “drift”: 仅运行第一阶段（漂移检查，无分类或模式检测）
• 如果目标是特定观察或紧张关系文件名：交互式分类单个项目

现在开始。 下面定义了六阶段工作流程。

---

哲学

系统不是神圣的。证据胜于直觉。

上下文文件中的每条规则，每个技能的工作流程，每个架构中烘焙的假设都曾是假设。假设需要根据现实进行测试。ops/observations/ 中的观察笔记捕获了实际使用中的摩擦。ops/tensions/ 中的紧张笔记捕获了未解决的冲突。重新思考首先单独分类这些（有些成为 {DOMAIN:notes}，有些成为方法论更新，有些被归档），然后比较剩余的证据与系统的假设，并在模式出现时提出更改。

这是将科学方法应用于知识系统：假设，实施，观察，修订。

没有这个循环，生成的系统就会僵化 — 它们会积累从未得到解决的摩擦，从未得到解决的矛盾，以及从未被提升到系统级更改的方法论学习。/rethink 是防止钙化的免疫系统。

---

阶段 0：漂移检查

规则零：ops/methodology/ 是系统操作方式的规范规范。在分类观察之前，检查系统是否已经偏离了方法论所说的应该做的事情。

0a. 加载方法论状态

# 获取所有带有元数据的方法论笔记
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  head -20 "$f"  # 前言带有类别、创建、更新、状态
  echo ""
done

完整阅读所有方法论笔记。提取：

• 每个笔记的类别、创建日期、更新日期、状态
• 每个笔记所做出的行为断言（“做什么”部分）

0b. 加载系统配置

阅读：

• ops/config.yaml — 当前配置状态
• 上下文文件（CLAUDE.md）— 当前行为指令
• ops/derivation-manifest.md — 词汇和功能状态

0c. 比较三种漂移类型

类型 1：过时

# 比较 config.yaml 修改时间与最新的方法论笔记
CONFIG_MTIME=$(stat -f %m ops/config.yaml 2>/dev/null || stat -c %Y ops/config.yaml 2>/dev/null || echo 0)
NEWEST_METH=$(ls -t ops/methodology/*.md 2>/dev/null | head -1)
METH_MTIME=$(stat -f %m "$NEWEST_METH" 2>/dev/null || stat -c %Y "$NEWEST_METH" 2>/dev/null || echo 0)

如果 CONFIG_MTIME > METH_MTIME: 配置自方法论上次更新以来已更改。标记为过时漂移。

类型 2：覆盖间隙

对于 config.yaml 中的每个活跃功能（具有 enabled: true 或在活动配置中存在的特性），检查是否存在相应的方法论笔记。没有方法论覆盖的功能代表间隙 — 系统做了它无法向自己解释的事情。

检查这些功能区域：

• 处理管道（有关处理行为的方法论笔记吗？）
• 维护条件（有关维护触发的方法论笔记吗？）
• 会话节奏（有关会话工作流程的方法论笔记吗？）
• 特定领域的行为（有关领域词汇和模式的方法论笔记吗？）

类型 3：断言不匹配

对于每个做出行为断言的方法论笔记（“做什么”部分），检查：

• 上下文文件是否包含与此指令一致或相矛盾的指令？
• config.yaml 是否包含与此指令一致或相矛盾的设置？
• 是否有其他方法论笔记与此相矛盾？

报告：哪些断言一致，哪些相矛盾，哪些没有相应的系统元素。

0d. 创建漂移观察

对于每个漂移发现，创建一个观察笔记在 ops/observations/：

---
description: [特定漂移发现]
category: drift
status: pending
observed: {今天的日期}
related_notes: ["[[methodology note]]", "[[config element]]"]
---
# [作为散文句的漂移发现]

**漂移类型：** staleness | coverage-gap | assertion-mismatch
**方法论笔记：** [[受影响的笔记]]
**系统元素：** [config.yaml 字段，上下文文件部分，或缺失的覆盖]
**差异：** [方法论所说的与系统所做的]


解决方案：更新方法论笔记 | 更新系统配置 | 标记人类审核

0e. 报告并继续

输出漂移状态摘要：

漂移检查：
  Staleness: [N findings — config changed, methodology not updated]
  Coverage gaps: [N features without methodology notes]
  Assertion mismatches: [N contradictions between methodology and system]
  Total drift observations created: [N]

如果创建了漂移观察，它们将加入待处理观察池，进入第一阶段分类。进入第一阶段。

---

阶段 1：分类

1a. 收集待处理证据

OBS_PENDING=$(grep -rl '^status: pending' ops/observations/ 2>/dev/null)
OBS_COUNT=$(echo "$OBS_PENDING" | grep -c . 2>/dev/null || echo 0)
TENSION_PENDING=$(grep -rl '^status: pending\|^status: open' ops/tensions/ 2>/dev/null)
TENSION_COUNT=$(echo "$TENSION_PENDING" | grep -c . 2>/dev/null || echo 0)

完整阅读每个待处理项目。这些是小的原子笔记 — 加载全部。理解全部内容是准确分类所必需的。如果零待处理项目，报告清洁状态并提前退出。

同时阅读 ops/methodology/ 以了解现有方法论笔记 — 这防止创建重复项，并通知新观察是否应该扩展现有方法论而不是创建新笔记。

1b. 对每个项目进行分类

为每个观察或紧张关系分配确切的一种处理方式：

处理方式	含义	应用时	操作
PROMOTE	值得作为永久 {DOMAIN:note} 保留的可重用洞察	跨会话的一般原则。可以作为主张笔记。结晶洞察，不是操作指导。	在 {vocabulary.notes}/ 中创建 {DOMAIN:note}，设置观察 status: promoted，添加 promoted_to: [[title]]
IMPLEMENT	应该改变系统的运营指导	“系统应该以不同的方式做 X。” 指向上下文文件、模板或技能的具体改进。	更新特定文件，设置 status: implemented，添加 implemented_in: [filepath]
METHODOLOGY	应该通知代理行为的摩擦模式	行为学习。不是领域洞察（PROMOTE）或系统更改（IMPLEMENT） — 有关如何操作的方法论学习。	在 ops/methodology/ 中创建或更新方法论笔记，设置 status: implemented，添加 implemented_in: ops/methodology/[file]
ARCHIVE	会话特定，不再相关	一个会话特定，没有持久价值。已由后续工作解决。被新证据取代。	设置 status: archived
KEEP PENDING	尚无足够证据	可能重要但需要更多数据。可能是尚未完全出现的模式的一部分。单个数据点可能会走向任何一方。	不变 — 保留 status: pending

观察分类启发式：

• 观察描述了跨会话有效的一般原则 → PROMOTE
• 观察说 “系统应该以不同的方式做 X” 并有具体文件/部分 → IMPLEMENT
• 观察描述了应该改变的代理行为（如何处理，何时检查，避免什么） → METHODOLOGY
• 观察是关于一个特定会话，没有持久价值 → ARCHIVE
• 观察可能重要但只出现了一次 → KEEP PENDING

紧张关系分类启发式：

• 紧张关系通过随后的更改得到解决 → ARCHIVE（设置 status: dissolved，添加 dissolved_reason）
• 紧张关系揭示了两个 {DOMAIN:notes} 之间的真正冲突 → PROMOTE（创建紧张 {DOMAIN:note} 或解决方案 {DOMAIN:note}）
• 紧张关系指向需要重新设计的系统工作流程 → IMPLEMENT
• 紧张关系是关于代理方法论 → METHODOLOGY
• 紧张关系是真实的，但解决方案不清晰 → KEEP PENDING

1c. 呈现分类表

在执行任何更改之前，向用户呈现完整的分类：

--=={ {DOMAIN:rethink} — 分类 }==--

  证据：[N] 观察，[M] 紧张关系

  PROMOTE ([count])
    [filename] — [title] → 拟议的 {DOMAIN:note} 标题
    [filename] — [title] → 拟议的 {DOMAIN:note} 标题

  IMPLEMENT ([count])
    [filename] — [title] → 更改 [specific file/section]
    [filename] — [title] → 更改 [specific file/section]

  METHODOLOGY ([count])
    [filename] — [title] → 创建/更新 ops/methodology/[name].md
    [filename] — [title] → 扩展现有的 ops/methodology/[name].md

  ARCHIVE ([count])
    [filename] — [title] — [归档原因]

  KEEP PENDING ([count])
    [filename] — [title] — [为什么需要更多证据]

使用 AskUserQuestion：“审查上述分类。批准全部，或列出要重新分类的项目（例如，‘保留 obs-003 待处理，提升 obs-007 代替’）。”

等待用户确认后才执行 1d。 未经批准，不要执行分类。

1d. 执行分类

在用户确认后，按顺序应用所有处理方式：

对于 PROMOTE 项目：

1. 在 {vocabulary.notes}/ 中创建 {DOMAIN:note}，标题为散文
2. 遵循标准笔记模式：YAML 前言（描述、类型、创建），主体发展洞察，主题页脚链接到相关 {vocabulary.topic_map}(s)
3. 观察内容成为笔记主体的种子 — 但要充分发展，不要只是复制观察
4. 更新观察：设置 status: promoted，添加 promoted_to: [[note title]]

对于 IMPLEMENT 项目：

1. 对确定的文件/部分进行具体更改
2. 对于非平凡的更改，向用户展示更改前后的对比，并在更改非平凡时获得确认
3. 更新观察/紧张关系：设置 status: implemented，添加 implemented_in: [filepath]

对于 METHODOLOGY 项目：（见第二阶段）

对于 ARCHIVE 项目：

1. 更新观察状态：status: archived
2. 对于被解散的紧张关系：status: dissolved，添加 dissolved_reason: [why]

对于 KEEP PENDING 项目：

1. 不变 — 保留原位

更新 MOCs： 分类执行后，更新 ops/observations.md 和 ops/tensions.md 以反映状态变化。将条目在待处理/提升/归档/解决/解散部分之间移动，视情况而定。

---

阶段 2：方法论文件夹更新

对于分类为 METHODOLOGY 的项目，在 ops/methodology/ 中创建或更新笔记。

创建新的方法论笔记

---
description: [这个方...（此处省略以保持格式不变）