检查或修复 Compound Engineering…

用于对 Compound Engineering 做轻量健康检查、修复仓库本地配置，或在用户批准后搭建 Compound Pack。

适用场景

解决思路

1. 交互时，使用当前工具列表中已有的宿主阻塞式提问工具逐项提问；按能力匹配，不按宿主特定名称匹配。工具出现在列表中即证明存在，绝不要调用面向用户的问题工具来探测其是否存在。
2. 若匹配的提问工具已列出但未加载，使用宿主的工具发现原语加载该能力，不要搜索其他宿主的工具名。
3. 仅当工具列表中没有此类工具，或真实提问调用报错时，才退回到宿主可见聊天界面上的编号列表；绝不静默跳过或自动配置。
4. `ce-setup` 只做轻量健康检查和仓库本地配置辅助，不批量安装所有可选依赖；缺失工具报告为可选能力，让用户只安装自己使用的工作流。
5. 当调用中指定要添加、创建或搭建 Compound Pack（`pack:<id>` 参数，或同样含义的文字请求）时，读取本技能目录的 `references/pack-scaffold.md` 并遵循它，替代 Phase 1-2（Diagnose 和 Fix Repo-Local Issues）：仅在用户批准后写入该 pack 及其配置条目，它自行运行健康检查，并汇报到 Phase 3（Summary）。
6. 解析 CE 工件根 `<root>` 时，读取 `<repo-root>/.compound-engineering/config.yaml` 中的 `docs_root`，其中 `<repo-root>` = `git rev-parse --show-toplevel`；只从该文件读取，不要从 `config.local.yaml` 读取；未设置时 `<root>` 为 `docs`，与之前完全一致。
7. 校验已设置的 `docs_root`：它必须是仓库相对目录，其真实、symlink 解析后的路径仍位于仓库内，且既不是仓库根，也不在 `.git/` 下；否则停止并报错，指出 `docs_root` 和该值，绝不回退到 `docs`。
8. 将 `<root>` 作为唯一工件位置：不存在就创建；每个路径组合为 `<root>/<subdir>` 并带本技能自己的子目录；绝不同时读取 `docs`。
9. Phase 1 Step 1：当平台暴露插件元数据或 manifest 时，通过读取它们来检测已安装的 compound-engineering 插件版本；若无法确定版本，则跳过本步。
10. 若找到版本，通过 `--version` 传给检查脚本；否则省略该 flag。
11. Phase 1 Step 2：运行脚本前显示：`Compound Engineering -- checking your environment...`。
12. 运行捆绑检查脚本；将 `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`。
13. 若 Step 1 无法确定版本，使用同一命令但不带 `--version VERSION`。
14. 若脚本不可用，运行 `references/repo-fixes.md` 中列出的内联等价检查。
15. 向用户显示诊断输出；缺失可选工具不是 setup 失败；健康报告包含解析后的 artifact root 以及由哪一配置层提供的信息（按 Artifact Root Resolution），显示该行以便操作员确认 CE 工件会写到哪里；缺失 `config.yaml` 是报告缺席，不是项目问题。
16. Phase 1 Step 3：健康报告指出的 repo-local 修复只适用于该报告诊断的 checkout；如果 Phase 2 将写入不同的可写 checkout，先诊断该 checkout；插件版本和可选工具等会话级发现仍来自本会话的 Phase 1。
17. 根据可写 checkout 可用性决定 Phase 2：如果本会话有可写 git checkout，就在本地运行 Phase 2，包括 `project_issues` 为 0 时；Phase 2 总是刷新示例，并在缺失时总是提议创建 `config.yaml`。
18. 如果本会话没有可写 checkout，但用户指定了仓库且 harness 暴露带可写 checkout 的远程 repo-work 界面，则在该界面运行 Phase 2，并在 Phase 3 报告远程 repo-local 修复。
19. 否则跳过 Phase 2 并进入 Phase 3，说明因没有可写 checkout 而跳过了 repo-local 写入。
20. 如果报告指出 legacy Compound Codex tool map，按本技能目录的 `references/legacy-codex-tool-map.md` 提议删除它；该块位于用户的 Codex home，而不是 checkout，因此无论 Phase 2 是否运行，该提议都成立。
21. 当报告指出以下项目问题时也要修复：过时的 `compound-engineering.local.md`；`.compound-engineering/config.local.yaml` 存在但未被安全 gitignore；`.compound-engineering/config.example.yaml` 缺失或过时；健康报告标记 `ce-work` skill 实现引擎不可用或无效、检测到已废弃的标量路由键、或报告休眠的 `work_engine_preferences` 格式错误或 `work_engine_effort` 格式错误；健康报告标记 `docs_root` 无效（`Invalid docs_root ...`）——修复前不会写入 CE 工件。
22. 如果缺失可选工具，不要提议批量安装；诊断已经打印了相关安装命令或项目 URL；说：“Install optional tools only for the workflows you use.”。
23. Phase 2：在做任何 repo-local 变更前，读取本技能目录的 `references/repo-fixes.md`；它包含 Steps 4-9：移除过时的 `compound-engineering.local.md`、刷新示例配置、提议创建 `config.yaml`、修复无效的 `work_engine_preferences` 和 `docs_root`、两个 `.gitignore` 提议，以及 agent-instructions 提议（knowledge-store mention、compounding directive、给 `ce-noslop` 的 chat-register directive）。
24. Phase 2：其中所有路径从仓库根解析（`git rev-parse --show-toplevel`），而不是 CWD；维护生成的示例文件是 Phase 2 自行完成的工作——刷新 `config.example.yaml` 并移除被取代的 `config.local.example.yaml`；对用户拥有文件的每次变更都要提议，并且仅在用户批准后应用。
25. Phase 3：渲染用户可运行的 invocation。setup 摘要默认用 `/ce-setup`；仅当活动宿主是 Codex 或明确记录 dollar-prefixed skill invocation 时用 `$ce-setup`；在 oh-my-pi (`omp`) 上用 `/skill:ce-setup`；只把 invocation 渲染为 inline code，且只输出一种形式。
26. Phase 3：显示简要摘要：`✅ Compound Engineering setup complete`，并列出 `Fixed:`（已应用修复或无）、`Skipped:`（被拒绝的修复或无）、`Optional:`（缺失的可选工具或全部可用），最后提示 `Run `<rendered invocation>` anytime to re-check.`。

适用边界 · 注意事项

• 不适用于没有安装 Compound Engineering 插件/技能及其脚本的项目或宿主。
• 当没有可写 git checkout 且没有可用的远程可写 repo-work 界面时，不执行 Phase 2 的仓库本地修复。
• 不要把它当作可选依赖的批量安装器；缺失工具只报告为可选能力。