/sdlc:init — 專案初始化

把這套流程接進目前的專案。跑完之後，其餘所有 /sdlc:* skills 都從 docs/agents/sdlc.md 讀參數，不需要再問任何設定。

已經有 docs/agents/sdlc.md 的專案：改成「更新模式」——讀出現值、 只問要改的部分，不要整份重來。

1. 訪談（一次問完，用表格呈現預設值）

先探測能自己查到的，查得到的不要問：

gh repo view --json nameWithOwner --jq .nameWithOwner   # 程式碼 repo
gh project list --owner @me --format json               # 既有的 Project 板
ls CLAUDE.md CONTEXT.md docs/adr docs/agents 2>/dev/null # 已有的結構
git worktree list                                        # 是否已用 worktree

驗證指令用專案型態推測預設值（*.csproj → dotnet build／dotnet test； package.json → npm test／npm run build；Makefile → make test……）， 列出來讓使用者確認或修改。

然後問（每題附建議值）：

1. 批准者是誰？（名字或稱呼——Research Review、Plan Review、Done 的擁有者）
2. Issue 開在哪個 repo？（可以和程式碼不同 repo；跨 repo 時所有 gh 指令都要帶 --repo）
3. 用哪個 GitHub Project 板？ 既有的（列出來選）或新建一個
4. 要不要 Epic 容器 issue？（多條產品線共用一個板時建議要）
5. 用不用 worktree 流程？（多 session 平行開發才需要）
6. 有沒有變異測試／契約檢查／本機部署驗證？（沒有就標「無」，DOD 會少那幾條—— 但要在設定檔留一行「無，補上時回來改」）
7. 有沒有對外承諾（合約、SLA、給客戶的確認單）？ 有 → 建 docs/obligations.md 義務對照表，sprint-review 會必查
8. 文件語言？（issue、spec、comment 用的語言）

2. 探測或建立 Project 板的 GraphQL ID

用既有的板：

# Project ID
gh project list --owner <owner> --format json --jq '.projects[] | "\(.number) \(.title) \(.id)"'

# Status 欄位與選項 ID（一次拿全）
gh api graphql -f query='query {
  node(id: "<PROJECT_ID>") {
    ... on ProjectV2 {
      field(name: "Status") {
        ... on ProjectV2SingleSelectField {
          id
          options { id name }
        }
      }
    }
  }
}'

新建板：gh project create --owner <owner> --title "<名稱>"，然後用 GraphQL 把 Status 欄位的選項改成十個階段（updateProjectV2SingleSelectField）： Todo、1.Research、1.Research Review、3.Plan、3.Plan Review、 4.Execute、4.Execute Review、5.Review、Final Review、Done。 改完再跑上面的查詢拿選項 ID。

⚠️ 拿到 ID 之後要實測一次才寫進設定檔：開一張測試 issue、走完 「開票三步驟」（見模板）、確認 Status 真的變了、再關掉刪掉。 ID 抄錯的症狀是 GraphQL 回 Could not resolve to a node—— 在 init 當場撞到，比在第一張正式票撞到便宜得多。

3. 產生檔案

模板在本 skill 目錄的 templates/（用 plugin 安裝路徑下的實際檔案，逐一讀入後替換 {{...}} 佔位）：

另建空目錄：docs/sprints/（放 sprint-review 與 retro 的紀錄）。

不要覆蓋任何已存在的內容——CLAUDE.md 用附加、其他檔案存在就跳過並回報。

4. 收尾

1. 把產生的檔案清單列給使用者
2. 印出快速上手：

一張 story 的完整生命週期：

  （討論需求）→ /sdlc:spec <issue>     ← 定 AC，設 1.Research Review，等批准
  批准後      → /sdlc:plan <issue>     ← 拆 task，設 3.Plan Review，等批准
  批准後      → 建票 → /sdlc:ticket-check <issue>   ← 金魚閘門
  過了        → /sdlc:implement        ← 寫程式（TDD）
  每張 task   → /sdlc:ship <task>      ← 驗證→commit→合併→CI→comment→自動接下一張
  全部完成    → 自動推進到 Final Review，等批准者給 Done

Sprint 邊界：/sdlc:sprint-review → /sdlc:retro（順序固定）
原則背景：sdlc plugin 的 docs/PRINCIPLES.md

3. 建議使用者 commit 這批新檔案（訊息：chore: 採用 Agent SDLC 流程）—— 但不要自己 commit，這是他的專案的第一個流程決定，該由他按下去。