根据目前的程式码库重新检视并更新储存库中已记录的经验（learnings）。适用于审查过时、重复、被替代或与实际程式码偏离的经验；除非经验储存库有明确指示，否则请勿用于一般的重构、除错或代码审查。
Compound Refresh
维持 <root>/solutions/ 内容随时间推移的品质。此流程会对照目前的程式码库审查现有经验，并更新依赖这些经验所衍生出的模式文档（pattern docs）。
Setup
在每次执行本 Skill 的初始阶段、尚未派发任何子 Agent（subagent）前先执行一次，并遵循其印出的指令——但若指令与本 Skill 自订的「向使用者提问」规则发生冲突（无论该规则适用于非互动模式或所有模式），一律以本 Skill 的规则为准，不发起任何阻塞式提问。在同一次执行过程中请勿重复执行；若后续再次呼叫本 Skill 或其它 Skill，则会各自运行其初始化程序。若环境中未安装 Node 执行环境（Node runtime），本 Skill 将直接按常规流程继续执行。
SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi
Mode Detection
检查呼叫时传入的参数是否包含 mode:non-interactive 或已弃用的别名 mode:headless。若包含其中任一参数，请将其从参数列表中移除（保留其余内容作为范围提示 scope hint），并以**非互动模式（non-interactive mode）**运行。两者同时存在并不构成冲突。
| 模式 | 适用时机 | 运作行为 |
|---|---|---|
| 互动模式（预设） | 使用者在线且可回应提问 | 在遇到模糊不清的状况时询问决策，并确认各项操作 |
| 非互动模式 | 参数中包含 mode:non-interactive 或旧版别名 mode:headless |
无需使用者互动。直接套用所有无争议的操作（保留 Keep、更新 Update、整合 Consolidate、自动删除 auto-Delete、证据充分时替换 Replace）。将有争议的案例标记为过时（stale）。最后产生一份摘要报告。 |
非互动模式规则
- 跳过所有使用者提问。 绝不暂停等待输入。
- 处理范围内的所有文档。 不提出缩小范围的询问——若未提供范围提示（scope hint），则处理所有文档。
- 尝试所有安全操作： 保留 Keep（无操作）、更新 Update（修正参考链接）、整合 Consolidate（合并并删除被涵括的文档）、自动删除 auto-Delete（符合无争议条件）、替换 Replace（证据充分时）。若写入成功，在报告中记录为已套用（applied）。若写入失败（例如权限不足），在报告中将该操作记录为**建议操作（recommended）**并继续执行——切勿停止或索取权限。
- 文件搬迁比照自动删除模式：仅在完全满足所有条件时直接套用，否则仅作建议。 仅在以下四个条件全数成立时，才自动套用非互动模式下的文件搬迁：（1） Frontmatter 与所在目录依据分类映射表判定不一致；（2）内容证据明确指向解决方向——确定是目录摆放错误而非 Frontmatter 写错；（3）目标分类目录已存在；（4）所有连入的引用均在储存库内部，且可透过机械化规则改写。只要有任一条件不成立——包括内容可能同时符合两种分类的文档——一律改为记录在「建议操作」下。分割（Splits）在非互动模式下永远仅作建议：决定是否分割属于检索价值的主观判断，并无绝对客观标准，因此请将提议的切分边界记录在「建议操作」下。
- 不确定时标记为过时（stale）。 若分类判断确实存在模棱两可之处（ Update vs Replace vs Consolidate vs Delete ），或 Replace 的证据不足，请在 Frontmatter 中将其标记为过时，写入
status: stale、stale_reason与stale_date。若连写入过时标记的操作也失败，则将其列入建议事项中。 - 采用保守的信心度标准。 在互动模式下，临界案例会向使用者提问；在非互动模式下，临界案例则直接标记为过时。宁可标注过时，也不要误做不恰当的操作。
- 务必产生最终报告。 报告是本流程的主要产出物。报告包含两个主要章节：已套用（Applied）（已成功写入档案的操作）与建议操作（Recommended）（无法直接写入的操作，附带完整理由，以便人工处理或由使用者以互动模式再次执行本 Skill）。不论获得了何种档案权限，报告的结构皆保持一致——唯一的区别仅在于各项操作落入哪个章节。
CONCEPTS.md 初始化建立请求
若被专属呼叫来建立或初始化 CONCEPTS.md（例如：「建立 CONCEPTS.md」、「构建概念图谱」、「设定共享词汇表」），由于此意图可能代表两项不同工作——建立词汇表文件或运行 <root>/solutions 的更新刷新——因此在继续之前必须先厘清意图。请使用平台提供的阻塞式提问工具：Claude Code 中使用 AskUserQuestion（若 Schema 未载入，先呼叫 ToolSearch 搭配 select:AskUserQuestion）、Codex 中使用 request_user_input、Antigravity CLI（agy）中使用 ask_question、Pi 中使用 ask_user（需安装 pi-ask-user 扩展）。仅当运行框架中不存在阻塞式工具或呼叫报错（例如 Codex 编辑模式）时，才回退至在对谈中使用编号选项——绝不能因为需要载入 Schema 就直接改用对谈回退。切勿静默跳过提问。提供以下两个选项：
- 建立 CONCEPTS.md（构建概念图谱） — 初始化全储存库级别的概念图谱并进行提交；仅跳过
<root>/solutions的分类阶段（阶段 0–4）。阅读references/concepts-vocabulary.md并遵循其初始化目标（Seed goal）与初始化范围（Scope of a seed）（全储存库范围）规则：从已宣告的领域模型（schema、核心型别、主要模型、顶层领域文档）中提取专案的核心领域名词，每项皆须符合筛选标准，数量由程式码库决定。撰写前言（参见阶段 4.5），依组织规则分组，并执行可发现性检查（Discoverability Check），确保AGENTS.md/CLAUDE.md能顺畅引导至该新文件。随后进入阶段 5（提交变更 Commit Changes），透过与更新流程相同的持久化写入流程，提交/发起 PR 以保存新的CONCEPTS.md及相关指令档编修——切勿让初始化的成果处于未提交状态。 - 执行完整的更新循环（refresh cycle） — 依下方的常规更新流程继续；
CONCEPTS.md将在阶段 4.5 中被自动初始化（若不存在）并完成整合校对。
在非互动模式下，由于没有使用者可供询问：预设直接执行更新循环（词汇表无论如何都会在阶段 4.5 中完成初始化与校对），并在报告中注明未单独执行全储存库级别的独立初始化。
Interaction Principles
以下原则仅适用于互动模式。在非互动模式下，请跳过所有使用者提问，并直接适用上述非互动模式规则。
遵循与 ce-brainstorm 相同的互动风格：
- 一次只问一个问题 — 请使用平台提供的阻塞式提问工具：Claude Code 中使用
AskUserQuestion（若 Schema 未载入，先呼叫ToolSearch搭配select:AskUserQuestion）、Codex 中使用request_user_input、Antigravity CLI（agy）中使用ask_question、Pi 中使用ask_user（需安装pi-ask-user扩展）。仅当运行框架中不存在阻塞式工具或呼叫报错（例如 Codex 编辑模式）时，才回退至纯文本编号选项——绝不能因为需要载入 Schema 就直接改用纯文本回退。切勿静默跳过提问。 - 当有自然选项时，优先使用多选一（multiple choice）
- 先从范围与意图切入，有需要时再逐步收敛
- 在尚未搜集到充分证据前，不要要求使用者做决定
- 先给出明确建议，并附上简短说明
目的并不是要强迫使用者逐项检查，而是要在摩擦最小的前提下，协助他们做出明智的维护决策。
Artifact Root
本 Skill 会审查并更新位于 <root>/solutions/ 下的经验文档。当您首次组合 <root>/solutions/ 路径时，请先解析出 <root> 的实际位置（依下方区块说明）；请将解析后的 <root>/solutions/ 路径传递给所有子 Agent，而非原始设定值。
<!-- ce-docs-root:start -->
在组合任何产物路径之前，请先解析出 CE 产物根目录 <root>。
- 读取
<repo-root>/.compound-engineering/config.local.yaml中的docs_root，若无则读取config.yaml；以第一个非空值为主（<repo-root>为git rev-parse --show-toplevel）。若未设定 -><root>预设为docs，与以往完全一致。 - 验证已设定的数值：必须是相对于 repo 的目录，且解析符号连结（symlink）后的实际路径需维持在 repo 内部，既不能是 repo 根目录，也不能位于
.git/之下。若不符合，请停止运作并抛出指明docs_root及其具体数值的错误信息——切勿静默回退至docs。 - 使用
<root>作为唯一的产物存放位置：若不存在请直接建立，将各个路径组合为<root>/<subdir>（搭配本 Skill 对应的子目录），且绝不回头读取docs。
<!-- ce-docs-root:end -->
Refresh Order
请按以下顺序执行更新：
- 优先审查各个独立的经验文档（learning docs）
- 记录哪些经验维持有效、被更新、被整合、被替换或被删除
- 接着再审查依赖这些经验的模式文档（pattern docs）
为什么要采用此顺序：
- 经验文档是基础核心证据
- 模式文档是由单项或多项经验衍生总结而来
- 过时的经验会让模式文档看起来比实际情况更加可信
若使用者一开场就指名某个模式文档，您可以先从该文档切入以了解其关切重点，但在修改该模式文档前，务必先检视背后支持它的经验文档。
Maintenance Model
针对每一个待处理的产物，将其分类为以下五种处置结果之一：
| 处置结果 | 含义 | 预设操作 |
|---|---|---|
| Keep（保留） | 内容依然准确且具有参考价值 | 预设不编修档案；在报告中标明已完成审查且维持可信 |
| Update（更新） | 核心解决方案仍正确，但参考引用已有所偏离 | 根据确凿证据直接在原文件进行编修 |
| Consolidate（整合） | 两份或多份文档高度重叠但皆属正确 | 将独有内容合并至规范文档（canonical doc）中，并删除被涵括的文档 |
| Replace（替换） | 旧产物已具有误导性，且已有明确更好的替代方案 | 建立可信的新产物，随后删除旧产物 |
| Delete（删除） | 不再有用、不再适用或缺乏独特性 | 直接删除档案 — 若日后有需要，可透由 Git 历史纪录复原 |
Core Rules
- 凭证据做判断。 下列信号仅作为参考依据，并非机械化的评分卡。请运用工程专业判断来决定产物是否依然值得信赖。
- 优先采用无需写入的 Keep（保留）。 切勿仅仅为了留下审查纪录而特地去更新文档。
- 让文档符合现实，而非要求现实配合文档。 当目前的程式码与经验文档记载不符时，请更新经验文档以反映最新的程式码。本 Skill 的职责是维护文档准确度而非代码审查——切勿询问使用者程式码变更究竟是「故意为之」还是「功能退化（regression）」。只要程式码变了，文档就应该同步更新。若使用者认为程式码有错，那是本工作流程之外的独立议题。
- 果断决策，减少提问。 当证据明确时（档案重命名、类别搬迁、参考连结失效），直接套用更新。在互动模式下，仅在正确操作确实存在模棱两可时才向使用者提问。在非互动模式下，将有争议的案例直接标记为过时（stale）而非发问。本流程的目标是实现自动化维护并保留人类对关键判断的把关，而不是对每个发现都抛出提问。
- 避免低价值的无谓修改。 切勿仅为了修正错字、修饰字词或进行无助于实质提升准确度与易用性的外观调整而编辑文档。
- 仅在有实质依据且证据确凿的偏离时才使用 Update（更新）。 在修正能实质提升准确度的前提下，路径、模组名称、相关连结、分类中元资料（metadata）、程式码片段以及明显过时的措辞皆属于合理的更新范畴。归错分类同样属于偏离：当文档所在的目录与其 Frontmatter 中的分类不符，或其内容毫无悬念地属于另一个现有的分类时，请按照 Update 流程的搬迁指引处理。
