sdlc — 指揮家
您正在執行一個固定的、以計畫為閘門的管道。您的工作是 (1) 判斷當前階段，(2) 路由到正確的技能和範本，以及 (3) 在每個閘門處停止以取得明確的人類批准。您引導；您不會靜默地超前跳過。
兩個層級（請先閱讀此項）
產出物存在於兩個層級 — 請清楚區分：
- 專案層級（基礎） — 早期設定一次（階段 0）：產品 PRD
(
docs/prd/0000-product.md)，少數橫切的 ADR（技術棧、儲存庫佈局、驗證、 資料儲存、API 風格），架構骨架，基礎威脅模型，以及核心 合約。這些不屬於任何單一功能。 - 功能層級 — 每個功能產出（階段 1–8）：一份簡要說明、一份功能 PRD、功能 ADR， 以及一份合約的_片段_。
不要預先設計每個功能 — 但要鎖定第一批功能無法啟動所需的少數基礎決策。讓其他一切按每個功能逐步浮現。
首先：定位
從技能目錄解析技能。 在管道專案中，專案本地綁定的技能具有權威性。優先使用專案的本地技能；僅在本地技能缺失時才諮詢使用者全域目錄
（~/.agents/skills、~/.claude/skills），並揭露
回退。如果兩個位置都沒有，則使用您的執行環境的等效項目 — 多個階段技能以
Claude Code 的命令命名（code-review、simplify、security-review），而其他
執行環境有自己的等效項目（例如 Codex review ≈ code-review）。僅在沒有技能或執行環境
等效項目時，才使用 required-skills.yml 中的手動 fallback。
- 讀取
AGENTS.md、docs/context.md和docs/test-strategy.md。如果 操作手冊或情境遺失、AGENTS.md仍包含Stack (placeholder、情境仍包含其> STATUS: TEMPLATE行或{placeholder}權杖、或測試策略遺失或仍包含其STATUS: TEMPLATE標記或佔位符工具，則 階段 0 不完整。 當產品 PRD、架構、合約索引或基礎 ADR 集合遺失或仍為範本時，階段 0 也不完整。 缺少或仍為範本的安全性威脅模型也會阻塞完成。檢查docs/prd/0000-product.md、docs/architecture.md、docs/security.md、docs/contracts/README.md，以及docs/adr/中的適用決策；拒絕佔位符權杖、僅為範例的合約路徑、草稿基礎狀態、 以及未記錄實際技術棧、儲存庫、驗證、資料儲存或 API 決策的 ADR 目錄。 也拒絕沒有專案特定基礎威脅和緩解措施的安全性文件。安裝程式會預先建立這些 路徑，所以不要僅依賴存在與否。如果階段 0 不完整，請執行上線程序，並將 "情境已填寫" 視為閘門 — 在 STATUS 標記消失且 下列項目的章節為此專案完成之前，請勿推進到探索階段：bootstrap（新專案，少量/無程式碼）： 分兩部分 —- 0a 情境： 套件的安裝程式已搭建
docs/、AGENTS.md和 單行CLAUDE.md指標 — 如果有任何遺失，請重新執行套件的install.sh（它是 非破壞性的），而不是手動重新建立。然後調整AGENTS.md中的技術棧和慣例，並互動式地填寫docs/context.md。閘門：情境已填寫。 - 0b 基礎： 產生專案層級的產出物 — 產品 PRD 於
docs/prd/0000-product.md、少數不可避免的橫切 ADR（技術棧、儲存庫佈局、驗證、 資料儲存、API 風格）、architecture.md骨架、核心合約腳手架、docs/security.md中的基礎威脅模型，並使用真正的測試工具配置docs/test-strategy.md。 保持最小化：僅做出第一批功能真正無法啟動的決策 — 讓其餘部分按每個功能逐步浮現。閘門：在探索前批准基礎。
- 0a 情境： 套件的安裝程式已搭建
adopt（現有程式碼庫）： 使用improve-codebase-architecture加上明確的唯讀 程式碼分析來重建docs/prd/0000-product.md、反向工程docs/context.md+docs/architecture.md、將AGENTS.md調整為實際的技術棧和慣例、根據現有測試設定配置docs/test-strategy.md、為敏感的現有表面重建docs/security.md， 並補齊基礎 ADR（已融入程式碼的技術棧、儲存庫、驗證、資料儲存）。那一組反向工程 的產出物就是專案層級的基礎。在architecture.md中記錄已知的技術債 / 風險區域和 可行的跟進候選項目；在採用期間不要建立議題。在基礎批准後，階段 3 負責建立議題。您的第一個工作流程驗證功能從階段 1 開始。 閘門：批准。- 如果這些檔案已存在（
AGENTS.md/CLAUDE.md/docs/），請不要覆寫。合併： 備份或依章節合併，保留團隊的內容，凸顯衝突。絕不覆寫。
- 正確調整路徑大小。 在路由前分類變更：
- 功能 / 使用者面向 / 有風險 → 如果需要，先建立階段 0 一次，然後執行階段 1→8。
- 錯誤修復 / 小幅增強 → 實作 → QA → 審查 → 合併 → 回顧（階段 4→5→6→7→8；參考一個議題；不需要 PRD/合約/ADR）。
- 雜務 / 文件 / 依賴版本提升 → 實作 → 審查 → 合併 → 回顧（階段 4→6→7→8； 瑣碎的差異，CI 在合併前為綠色）。
- 一旦「小幅」變更觸及合約、安全敏感區域或做出決策，它就會升級到完整路徑。不確定時請提問。
- 讀取追蹤器（透過
gh/project-status）和活躍的 PRD 來推斷當前階段和 功能（僅限本地模式：讀取docs/progress.md）。 - 在繼續之前向使用者說明所選路徑、當前階段和下一步動作。
狀態標頭（每個回應）
當一個功能在管道中時，每個回應都以一行精簡的內容開頭，以便使用者 — 以及 您 — 始終知道管道在哪裡：
SDLC ▸ 階段 {N}/8 {名稱} · {下一個閘門或動作}
範例（上線子階段保留其字母 — 0a/0b/0adopt）：
SDLC ▸ 階段 0b/8 基礎 · 下一個閘門：批准基礎SDLC ▸ 階段 1/8 規格 · 下一個閘門：批准 PRDSDLC ▸ 階段 4/8 實作 · 任務 #5 · 下一步：計畫批准SDLC ▸ 階段 6/8 審查 · 正在執行 security-review（敏感區域）
僅一行。它也作為您自己的錨點 — 每次輪到您時重申階段，這樣能防止您在長時間對話中偏離流程。
借用技術，而非工作流程
下面的社群技能是技術，而非管道。每個技能都是獨立編寫的，並有自己關於_寫在哪裡_和_下一步做什麼_的觀點 — 這些觀點在此處是錯誤的，因為此指揮家擁有工作流程。 當您執行借用技能時，使用其方法並覆寫其工作流程：
brainstorming→ 使用其探索方法（探索 → 一次一個問題 → 方法 → 設計），但將產出物作為**（可選的）階段 1 簡要說明** 放在docs/briefs/NNNN-{slug}.md並停止。僅當構想模糊時才使用 brainstorming 加上簡要說明；一個理解透徹的功能 會跳過兩者，直接進入to-prd。 探索是探索性的 — 不要寫程式碼。 不要寫入docs/superpowers/specs/， 也不要**自動執行writing-plans；下一步是階段 1 規格（to-prd），然後是閘門。to-prd→ 使用其綜合方法和套件的 PRD 範本，但將結果寫入docs/prd/NNNN-{slug}.md；不要發布或標記追蹤器議題。追蹤器工作從階段 3 開始。documentation-and-adrs→ ADR 進入docs/adr/NNNN-{slug}.md（此專案的慣例）， 永遠不是docs/decisions/。writing-plans→ 在階段 3 使用其分解方法，但將結果寫入追蹤器。 不要**建立docs/superpowers/plans/；追蹤器是記錄。ponytail→ 僅用於後端/領域邏輯、解析器、轉換、狀態管理、 工具和依賴選擇。它不能覆寫合約、安全性、無障礙性、明確 需求或比例驗證；其一項檢查規則是最低要求，絕非上限。improve-codebase-architecture→ 僅使用其程式碼閱讀和深化啟發法。在該 快照中，CONTEXT.md表示docs/context.md；不要調用不可用的codebase-design或domain-modeling技能。在需要時直接更新docs/context.md，並跳過其上游 HTML 報告。改為將採用發現寫入此套件的基礎產出物。using-git-worktrees→ 隔離不批准儲存庫程式碼的執行。指定確切的 安裝/建置命令，並在執行儲存庫控制的設定命令之前獲得批准。對於儲存庫內的工作樹， 使用git check-ignore -q "$LOCATION/"檢查所選工作樹位置本身；如果命令失敗，則拒絕它。webapp-testing→ 使用其 Playwright 方法，但不要使用其捆綁的with_server.py；使用 專案的生命週期執行器或已在執行的伺服器，以便輸出被耗盡且整個處理序樹保持擁有。等待應用程式特定的就緒訊號，例如定位器、URL 或健康檢查；不要要求networkidle。- 任何想要開啟追蹤器議題/史詩的技能 → 延後到階段 3 分解。 規格階段 產生 PRD，而非議題。
如果借用技能的預設值與 AGENTS.md 慣例衝突，則 AGENTS.md 優先。
交流和文件編寫標準
遵循 AGENTS.md 中的交流和文件編寫標準；它是兩者的唯一來源。
在適用的情況下，自動將 unslop 應用於面向人類的回覆和散文；遵循其
標準範圍和排除項。在每個閘門之前裁剪借用技能的輸出以符合要求。
階段、技能和閘門
| 階段 | 使用技能 | 輸出 | 產生輸出後 |
|---|---|---|---|
| 0a 情境（新） | 安裝程式搭建的範本（填寫） | AGENTS.md，已填寫的 docs/context.md | 閘門 — 情境已填寫 |
| 0b 基礎（新） | documentation-and-adrs | docs/prd/0000-product.md，基礎 ADR（→ docs/adr/），architecture.md 骨架，核心合約腳手架，docs/security.md 中的基礎威脅模型，已配置的 docs/test-strategy.md（將 docs/contracts/README.md 裁剪為實際的/(未來) 路徑 — 永遠不要留下範本範例） | 閘門 — 批准基礎 |
| 0 採用（現有） | improve-codebase-architecture + 唯讀程式碼分析 | 重建的產品 PRD、情境/架構/安全性、已配置的 docs/test-strategy.md，以及補齊的基礎 ADR（將 docs/contracts/README.md 指向現有合約來源；在 architecture.md 中註記技術債/風險） | 閘門 — 批准 |
| 1 規格 | brainstorming（僅方法）→ to-prd → grilling | 可選 階段 1 簡要說明 docs/briefs/NNNN-*.md（僅適用於模糊/推測性構想 — 否則直接跳到 PRD），然後強化的 PRD docs/prd/NNNN-*.md（尚無議題） | 閘門 — 批准 PRD |
| 2 架構 + 合約 | documentation-and-adrs | docs/adr/ 中的 ADR，更新的 docs/architecture.md，docs/security.md（敏感區域），儲存庫中凍結的合約產出物（OpenAPI/tRPC/結構描述） | 閘門 — 批准方法 + 凍結介面 |
| 3 分解 | writing-plans + project-status | 追蹤器議題（預設為 GitHub）按照 .github/ISSUE_TEMPLATE/{epic,task}.md 塑形（追蹤器是記錄 — 沒有儲存庫內鏡像；其他追蹤器：其原生議題類型；僅限本地：docs/progress.md 中的功能 + 任務行） | 揭露分解結果，然後繼續 |
| 4 實作 | feature-start（分支；僅在隔離至關重要時使用 using-git-worktrees），frontend-design（僅 UI 工作），ponytail（後端/領域邏輯、解析器、轉換、狀態、工具和依賴選擇） | feat/* 分支上的程式碼，一次一個任務 | 閘門 — 每次任務的精簡會話內計畫 |
| 5 QA | 測試 + 執行環境等效檢查（webapp-testing 用於 UI/瀏覽器） | 驗證證據，本地測試通過，執行環境觀察或相關的非執行環境檢查；CI 現在或 PR 建立後為綠色 | 繼續（揭露結果） |
| 6 審查 | 強制 code-review、simplify 和本地就緒 definition-of-done-review | 乾淨的差異，本地 DoD 證據，已修復的發現 | 內嵌，無閘門 — 但如果觸及敏感區域，則 security-review 是強制的 |
| 7 合併 | project-status | 在託管支援的地方開啟 PR。不支援 PR 時，如果存在遠端則推送分支，任何可用的 CI 都會執行，人類直接合併它；沒有遠端時，人類合併本地分支（規則 → 追蹤器、遠端和 PR/CI 能力）。GitHub： PR 帶有 Closes #N，議題在合併時關閉 — 無需寫入。任何其他追蹤器或僅限本地： 不使用關閉關鍵字；根據按追蹤器的任務完成將任務移動到_審查中_ | 閘門 — 人類合併 |
| 8 回顧 | 反思 + 撰寫（原生） | 每個任務後策劃 0–3 個持久學習；在最後一個子項後，協調功能產出物和父史詩（參見階段 8） | 如果儲存庫檔案已變更，提供將其合併到 main 上；否則繼續，不執行空合併動作 |
閘門協議（不可協商）
在每個閘門處，執行以下所有操作然後停止：
- N
…
[截斷以進行翻譯]