檢查 Compound Engineering 健康狀況與專案儲存庫的本地設定。
Compound Engineering 設定
互動方式
請使用目前平台的阻塞式提問工具（blocking question tool）詢問下方每個問題：在 Claude Code 中使用 AskUserQuestion（若其 schema 未載入，請先使用 select:AskUserQuestion 呼叫 ToolSearch）、在 Codex 中使用 request_user_input、在 Antigravity CLI (agy) 中使用 ask_question、在 Pi 中使用 ask_user（需要安裝 pi-ask-user 擴充功能）。僅在執行環境（harness）中不存在任何阻塞式工具或呼叫發生錯誤時，才退回到對話中的編號列表。切勿默默跳過或自動配置。
ce-setup 是一個輕量級的健康檢查與儲存庫本地設定輔助工具。它不會批量安裝所有可選的相依套件。缺失的工具會以「可選功能」形式呈報，讓使用者僅安裝自身工作流程所需的工具。
產出物根目錄解析（Artifact Root Resolution）
每個會寫入或讀取產出物目錄（solutions、plans、ideation 以及其他 CE 擁有的目錄樹）的 Compound Engineering Skill，都會透過以下規則解析其根目錄。ce-setup 包含此標準規範並回報解析後的根目錄，以便操作人員在執行其他 Skill 之前，能先確認產出物的存放位置。
<!-- 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，與先前完全一致。 - 驗證：若有設定值，必須為專案相對路徑，且經符號連結（symlink）解析後的真實路徑需位於儲存庫內部，既不能是儲存庫根目錄，也不能在
.git/目錄下。否則應中斷並印出包含docs_root及其設定值的錯誤訊息——切勿退回使用docs。 - 使用：將
<root>作為唯一的產出物存放位置：若不存在則建立它，並將所有路徑組合為<root>/<subdir>（搭配該 Skill 自身的子目錄），切勿同時讀取docs。
<!-- ce-docs-root:end -->
第一階段：診斷
步驟 1：判定外掛程式版本
當平台提供相關介面時，透過讀取外掛程式中繼資料（metadata）或清單（manifest）來偵測已安裝的 compound-engineering 外掛程式版本。如果無法判定版本，請跳過此步驟。
若有找到版本，請透過 --version 傳遞給檢查腳本；否則省略該標籤。
步驟 2：執行健康檢查
在執行腳本之前，請先顯示：
Compound Engineering -- checking your environment...
執行隨附的檢查腳本。將 SKILL_DIR 設定為載入此 ce-setup SKILL.md 的絕對路徑——因為 Bash 工具的 CWD（當前工作目錄）是使用者的專案目錄而非 Skill 目錄，直接使用 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。
若無法使用該腳本，請執行等效的內聯（inline）檢查：
- 使用
command -v檢查可選工具：agent-browser、gh、jq、ast-grep、ffmpeg。 - 若位於 git 儲存庫內，請透過
git rev-parse --show-toplevel解析儲存庫根目錄。 - 檢查儲存庫根目錄下是否存在已廢棄的
compound-engineering.local.md。 - 檢查
.compound-engineering/config.local.yaml是否存在；若存在，檢查git check-ignore -q .compound-engineering/config.local.yaml是否成功。 - 在可讀取範本的前提下，比較
.compound-engineering/config.local.example.yaml與references/config-template.yaml；否則提示需手動更新範例。
將診斷結果顯示給使用者。缺少可選工具並不代表設定失敗。健康檢查報告包含解析後的產出物根目錄及提供該設定的層級（詳見前述「產出物根目錄解析」）；請呈現該行訊息，以便操作人員確認 CE 產出物的寫入路徑。
步驟 3：判定是否需要修復
使用者可執行的呼叫指令格式化：在設定摘要中，預設使用 /ce-setup；僅當目前宿主環境為 Codex，或明確記載使用前綴 $ 呼叫 Skill 時，才使用 $ce-setup。呼叫指令需渲染為內聯程式碼，且僅輸出其中一種格式。
僅在存在一個或多個專案本地問題時，才進入第二階段：
- 存在已廢棄的
compound-engineering.local.md .compound-engineering/config.local.yaml存在，但未被安全地加入 gitignore.compound-engineering/config.local.example.yaml缺失或已過期- 健康檢查報告標示
ce-work的 Skill 實作引擎不可用或無效、偵測到已停用的單一純量（scalar）路由金鑰，或呈報格式錯誤的休眠work_engine_preferences - 健康檢查報告標示
docs_root無效（Invalid docs_root ...）——修復前將無法寫入 CE 產出物
若不存在任何專案問題，請回報：
✅ Compound Engineering setup complete
Project config: ✅
Optional capabilities: see diagnostic report above
Run `<rendered invocation>` anytime to re-check.
如果缺少可選工具，請勿提供批量安裝選項。診斷報告已印出對應的安裝命令或專案 URL。請提示：「請僅針對您使用的工作流程安裝可選工具。」
第二階段：修復專案本地問題
解析儲存庫根目錄（git rev-parse --show-toplevel）。以下所有路徑皆相對於儲存庫根目錄，而非當前工作目錄。
步驟 4：移除已廢棄的本地設定
如果儲存庫根目錄下存在 compound-engineering.local.md，請向使用者說明該檔案已廢棄，因為審查 Agent（review-agent）的選擇現已自動化，且留存的本機設定目前均存放於 .compound-engineering/config.local.yaml。
詢問是否立即刪除。僅在使用者同意後方可刪除。
步驟 5：更新範例設定
將 references/config-template.yaml 複製至 <repo-root>/.compound-engineering/config.local.example.yaml（若目錄不存在請予以建立）。該檔案會提交至儲存庫中，應始終反映最新可用的設定選項。
若目前平台無法找到隨附的範本，請印出失敗的來源範本路徑，並告知使用者無法自動更新範例設定。
步驟 6：根據需要建立本地設定
如果 .compound-engineering/config.local.yaml 不存在，請詢問：
Set up a local config file for this project?
This saves optional Compound Engineering preferences such as output formats and product pulse settings.
Everything starts commented out -- you only enable what you need.
1. Yes, create it
2. No thanks
若使用者同意，將 references/config-template.yaml 複製至 <repo-root>/.compound-engineering/config.local.yaml。
步驟 6a：修復無效的 CE Work 偏好設定
當健康檢查報告標示 CE Work 的實作引擎不可用或無效、偵測到已停用的單一純量路由金鑰，或呈報格式錯誤的休眠 work_engine_preferences 時，切勿通靈猜測預期的接收者。請向使用者說明報告所指出的確切問題，根據使用者說明的執行環境/模型順序推導出合法的有序 work_engine_preferences 區塊（或者當使用者希望預設採用原生模式時，移除格式錯誤的休眠偏好設定並改用 work_engine_mode: off），移除任何已停用的單一純量路由金鑰，並展示完整的替換區塊。僅在使用者批准預覽後方可編輯這些 CE Work 相關金鑰，且必須保留所有無關的本地設定。重新執行健康檢查，並要求其在設定完成前回報原生模式或預期的正規化有序列表。
步驟 6b：修復無效的 docs_root
當健康檢查報告標示 docs_root 無效時，請向使用者說明報告給出的確切原因（絕對路徑、超出儲存庫範圍、.. 穿越路徑、儲存庫根目錄、.git/ 或非目錄組件）以及產生的後果：在修復之前將無法寫入 CE 產出物，因為 docs_root 在出錯時會採安全關閉（fail closed）機制，而非默默退回使用 docs。docs_root 可能存在於已被版本控制的 .compound-engineering/config.yaml 或本地的 config.local.yaml 中，並優先採用本地設定。請提供選項供使用者選擇：將該值修正為使用者指定之合法的儲存庫相對目錄，或是直接移除有問題的 docs_root 金鑰。請精準提示退回機制：移除該金鑰會退回至下一個有設定 docs_root 的層級（例如刪除 config.local.yaml 中有問題的值，會讓位給已被版本控制的 config.yaml 中所設定的 docs_root），只有當所有層級皆未設定時才會退回預設的 docs——因此當兩個層級皆包含設定值時，需在每一個提供不良設定的層級中修復或移除該值。僅在使用者批准後編輯這些金鑰，並保留所有無關的設定。重新執行健康檢查，要求其在設定完成前回報已成功解析的產出物根目錄。
步驟 7：確保本地設定已被加入 Gitignore
若 .compound-engineering/config.local.yaml 存在且未被 .gitignore 涵蓋，請提供加入以下規則的選項：
.compound-engineering/*.local.yaml
僅在使用者同意後，將該條目附加至儲存庫根目錄的 .gitignore 尾端。切勿覆蓋無關的 .gitignore 內容。
第三階段：摘要
顯示簡短摘要：
✅ Compound Engineering setup complete
Fixed: <repo-local fixes applied, or none>
Skipped: <repo-local fixes declined, or none>
Optional: <missing optional tools, or all available>
Run `<rendered invocation>` anytime to re-check.
