Menu
自動偵測或互動式建立自訂技術棧 —— 掃描專案分層結構產生範本掃描規則，寫入設定檔。當使用者提到 /plan-stack、「自訂技術棧」、「新增掃描技術棧」時觸發此 Skill。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
CREW 環境健診 —— 一次性檢查 CREW 所有必要與選配依賴（Node/Git/Notion MCP/Agent Teams/瀏覽器 MCP/config/專案註冊/CLAUDE.md），列出綠黃紅燈與修法。當使用者提到 /crew-doctor、「CREW 環境健診」、「CREW 為什麼不能用」時觸發此 Skill。
瀏覽與探索已有的 .spec/ 規劃文件 —— 深度閱讀、跨任務比較、模式搜尋。當使用者提到 /plan-browse、「瀏覽 .spec 規劃」、「看之前的規劃設計」時觸發此 Skill。
從 .spec/{slug}/plan.md 以 Agent Teams leader-delegate 模式產生程式碼，含退出驗證與錨點有效性檢查，Leader 只協調不寫 code。當使用者提到 /plan-build、「從 spec 產生程式碼」、「plan-build 產碼」時觸發此 Skill。
結案前先跑文件漂移硬關卡（FAIL 擋、WARN 需明示放行），通過後蓋章 verified_at_commit、提交 Git、批次同步 plan.md 與 deploy.sql 到 Notion。當使用者提到 /plan-close、「feature 結案」、「同步 spec 到 Notion 並結案」時觸發此 Skill。
智慧推薦 CREW 當前任務下一步 —— 呼叫 crew-state.py 讀 state.json 算出下一個 /plan-* 指令並轉成人話。當使用者提到 /plan-next、「CREW 下一步指令」、「這個 spec 接下來做什麼」時觸發此 Skill。
CREW 規劃 —— spec / db / arch 三個 pass 把決策與驗收條件寫進 .spec/{slug}/plan.md，DB 設計另產 deploy.sql（零 Notion 呼叫）。當使用者提到 /plan、「CREW 完整規劃」、「一次跑完 spec/db/arch」時觸發此 Skill。
| name | plan-stack |
| description | 自動偵測或互動式建立自訂技術棧 —— 掃描專案分層結構產生範本掃描規則，寫入設定檔。當使用者提到 /plan-stack、「自訂技術棧」、「新增掃描技術棧」時觸發此 Skill。 |
自動掃描專案的分層結構，偵測各層級的 package 與命名慣例，產生範本掃描規則並寫入設定檔。
依 plugin 根目錄 references/config-resolver.md（相對 SKILL.md 為 ../../references/）的解析邏輯載入設定目錄。技術棧檔案寫入 stacks/{id}.md。
前置檢查：參照 plugin 根目錄
references/prerequisites.md（相對 SKILL.md 為../../references/）檢查 CLAUDE.md 是否存在。
/plan-stack [技術棧 ID]
stacks/_builtin.md 取得內建 ID 清單stacks/{id}.md 是否已存在目前範本以 Java（Maven/Gradle）專案為例；非 Java 專案請參照下方「邊界情況」改用對應語言的建置檔與 Pattern。
掃描建置檔（pom.xml / build.gradle），擷取框架、ORM、DB。
驗證：不可與內建 ID（spring-mvc-mybatis、spring-boot-mybatis、spring-boot-jpa、spring-boot-mybatis-plus）或已有的自訂 ID 重複，格式為小寫英文 + 數字 + 連字號。此檢查為硬性擋下，不提供「覆蓋內建」的選項——原因見下方 Gotchas。
掃描 src/main/java 下的 package 結構，辨識各層級並產生 Glob Pattern。
| 辨識規則 | 層級 |
|---|---|
entity / model / pojo / domain | Entity |
dao / mapper / repository | Repository/Mapper |
mapping + .xml | Mapper XML |
service (無 impl) | Service |
service/impl | ServiceImpl |
controller / rest / api | Controller |
dto / vo | DTO |
展示層級表格，支援確認/編輯/取消。
建立或更新 stacks/{id}.md，格式參照 plugin 根目錄 references/config.template.md（相對 SKILL.md 為 ../../references/）的自訂技術棧模板：
---
id: {技術棧 ID}
framework: {框架}
orm: {ORM}
db: {DB}
scaffold: {scaffold 行為}
---
## 掃描規則
| 層級 | 說明 | Glob Pattern | 範例 Package |
|------|------|-------------|-------------|
| ... | ... | ... | ... |
## 特殊慣例
- ...
同時更新對應專案的 projects/{repo-id}.md 中的 stack 欄位。
自訂技術棧設定完成！
技術棧檔案：{設定目錄}/stacks/{id}.md（{設定目錄} 依 `references/config-resolver.md` 解析結果代入，通常為 ~/.claude/feature-workflow）
層級數：{N}
現在執行 /plan-build 時會自動使用此技術棧的掃描規則。
/plan-setup 或 /crew-init/project-addspring-mvc-mybatis、spring-boot-mybatis、spring-boot-jpa、spring-boot-mybatis-plus。依 references/config-resolver.md 的解析邏輯，凡專案 stack 欄位值屬於內建 ID，一律讀取 stacks/_builtin.md 中的對應區塊，不會去讀同名的 stacks/{id}.md；因此就算手動用內建 ID 建立自訂檔案，該檔案也不會被套用（不是「靜默覆蓋內建定義」，而是自訂檔案本身失效、不生效）。步驟 3 會擋下此重複，若要調整內建行為，須改用不同的自訂 ID，並更新對應專案的 projects/{repo-id}.md 之 stack 欄位指向新 ID。repository 而非 dao 時仍可辨識，但非標準命名（如 persistence、store）可能辨識失敗。掃描結果必須展示給使用者確認（見「展示結果並確認」一節），不可跳過。/plan-setup/project-add