ce-setup

Compound Engineering 设置

交互方式

使用当前工具列表中已有的宿主阻塞式提问工具，依次提出以下每个问题（按功能匹配，不按宿主特定名称匹配）。工具出现在当前工具列表中，即证明该工具存在；切勿调用面向用户的提问工具来探查其是否存在。如果匹配的工具已列出但尚未加载，请使用宿主的工具发现原语加载该功能——不要搜索其他宿主的工具名称。只有当列表中没有此类工具，或实际提问调用报错时，才在宿主面向用户的聊天界面上改用编号列表。切勿悄悄跳过或自动配置。

ce-setup 是一个轻量级健康检查和仓库本地配置助手。它不会批量安装所有可选依赖项。缺少的工具会作为可选功能报告，以便用户只安装自己会用到的工作流所需工具。

Pack 脚手架

当调用请求中提到要添加、创建或搭建 Compound Pack（pack:<id> 参数，或以文字提出相同请求）时，请阅读此技能目录中的 references/pack-scaffold.md，并以其中流程替代第 1–2 阶段（诊断和修复仓库本地问题）：只有在用户批准后才写入 Pack 及其配置项，自行运行健康检查，并将结果报告到第 3 阶段（总结）。

工件根目录解析

每个会读写工件目录（solutions、plans、ideation 以及其他 CE 管理的目录树）的 Compound Engineering 技能，都必须按照下列规则解析其根目录。ce-setup 负责提供权威说明并报告解析出的根目录，以便操作人员在运行其他技能前确认工件的存放位置。

在构造任何工件路径之前，先解析 CE 工件根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.yaml 中的 docs_root（<repo-root> = git rev-parse --show-toplevel）。不要从 config.local.yaml 读取。未设置时，<root> 与以往一样为 docs。
• 验证已设置的值：它必须是相对于仓库的目录，其实际路径（解析符号链接后）仍位于仓库内，且既不能是仓库根目录，也不能位于 .git/ 下。否则停止并报错，指出 docs_root 及其值——绝不可回退到 docs。
• 使用 <root> 作为唯一工件存放位置：若目录不存在，则创建；将每个路径构造成 <root>/<subdir>，其中 <subdir> 为此技能自己的子目录；绝不同时读取 docs。

第 1 阶段：诊断

第 1 步：确定插件版本

如果平台提供插件元数据或清单，则通过读取它来检测已安装的 compound-engineering 插件版本。如果无法确定版本，则跳过此步骤。

如果找到了版本，请通过 --version 将其传递给检查脚本。否则省略此标志。

第 2 步：运行健康检查

运行脚本之前，显示：

Compound Engineering -- checking your environment...

运行附带的检查脚本。将 SKILL_DIR 设置为加载此 ce-setup SKILL.md 的绝对目录——Bash 工具的 CWD 是用户的项目目录，而不是技能目录，因此仅使用 scripts/ 路径将无法解析：

SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
if [ -f "$SKILL_DIR/scripts/check-health" ]; then bash "$SKILL_DIR/scripts/check-health" --version VERSION; else echo "Bundled health script not found at $SKILL_DIR/scripts/check-health; run the inline checks from ce-setup instead."; fi

如果第 1 步无法确定版本，请使用相同命令，但不带 --version VERSION。

如果脚本不可用，请运行 references/repo-fixes.md 中列出的内联等效命令。

向用户显示诊断输出。缺少可选工具不算设置失败。健康报告包含解析出的工件根目录及提供该值的配置层（根据上述工件根目录解析规则）；请显示该行，以便操作人员确认 CE 工件的写入位置。缺少 config.yaml 会作为未找到报告，不属于项目问题。

第 3 步：判断是否需要修复

健康报告列出的仓库本地修复仅适用于报告诊断的检出版本。如果第 2 阶段要写入另一个可写检出版本，请先诊断该检出版本。插件版本和可选工具等会话级结果仍来自本会话的第 1 阶段。

查看健康报告后，根据是否有可写检出版本来决定是否执行第 2 阶段：

• 如果本会话有可写的 git 检出版本，请在本地运行第 2 阶段，即使 project_issues 为 0 也如此。第 2 阶段始终会刷新示例，并且在缺少 config.yaml 时始终会询问是否创建该文件。
• 如果本会话没有可写检出版本，但用户指定了一个仓库，且执行环境提供了带有可写检出版本的远程仓库操作界面，请改在该界面上运行第 2 阶段，并在第 3 阶段报告远程仓库本地修复。
• 否则，跳过第 2 阶段并进入第 3 阶段，说明由于没有可写检出版本，已跳过仓库本地写入。

有两项询问针对的是本机，而不是检出版本，因此无论是否运行第 2 阶段，都应进行。如果报告指出存在旧版 Compound Codex 工具映射，请按照此技能目录中的 references/legacy-codex-tool-map.md 提出移除建议。如果捆绑的健康脚本报告 node 行可用，请按照 references/acpx-cache-warm.md 提出为跨模型对等端预热 npm 缓存的建议。

报告指出以下项目问题时，也要进行修复：

• 已过时的 compound-engineering.local.md
• .compound-engineering/config.local.yaml 存在，但未安全地加入 gitignore
• 缺少或过时的 .compound-engineering/config.example.yaml
• 健康报告指出 ce-work 技能的实现引擎不可用或无效、检测到已弃用的标量路由键，或报告了格式错误的休眠 work_engine_preferences 或格式错误的 work_engine_effort
• 健康报告指出 docs_root 无效（Invalid docs_root ...）——修复前不会写入 CE 构件

如果缺少可选工具，不要提出批量安装建议。诊断已打印相关的安装命令或项目 URL。请说：“仅为你会使用的工作流安装可选工具。”

第 2 阶段：修复仓库本地问题

在进行任何仓库本地更改之前，请阅读此技能目录中的 references/repo-fixes.md。该文件包含第 4 至第 9 步：移除过时的 compound-engineering.local.md、刷新示例配置、询问是否创建 config.yaml、修复无效的 work_engine_preferences 和 docs_root、两项 .gitignore 询问，以及 Agent 指令相关的询问（知识库提及、复利指令和针对 ce-noslop 的聊天登记指令）。

其中所有路径均以仓库根目录（git rev-parse --show-toplevel）为基准，而非当前工作目录。第 2 阶段自行执行的工作是维护生成的示例文件——刷新 config.example.yaml 并移除被取代的 config.local.example.yaml。每项对用户拥有的文件所做的更改，都必须先征得用户同意，只有用户批准后才能应用。

第 3 阶段：总结

可由用户运行的调用方式。 在设置摘要中，默认使用 /ce-setup；只有当当前宿主是 Codex，或文档明确说明技能调用使用美元符号前缀时，才使用 $ce-setup。在 oh-my-pi（omp）上，使用 /skill:ce-setup。仅将调用方式写成行内代码，并且只输出一种形式。

显示简短摘要：

✅ Compound Engineering setup complete

Fixed:     <fixes applied, or none>
Skipped:   <fixes declined, or none>
Optional:  <missing optional tools, or all available>

Run `<rendered invocation>` anytime to re-check.