القائمة
為已完成的專案新增需求變更（Change Request）。spec-writer 評估影響範圍 → 建立 CR 文件 + 新 Sprint milestone → 走原本的 tech-lead → engineer + qa → verify 流程。觸發關鍵字："change", "新需求", "需求變更", "CR", "後續功能", "新增功能"。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | specflow:change |
| description | 為已完成的專案新增需求變更（Change Request）。spec-writer 評估影響範圍 → 建立 CR 文件 + 新 Sprint milestone → 走原本的 tech-lead → engineer + qa → verify 流程。觸發關鍵字："change", "新需求", "需求變更", "CR", "後續功能", "新增功能"。 |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash, Agent, AskUserQuestion |
| argument-hint | [變更描述] |
當專案已 release 但需要新增/修改功能時，用這個流程。不是改 spec 重來，而是把變更當作新的迭代層疊上去，並透過既有 e2e tests 自動形成回歸測試。
Bug fix 不要用這個流程，直接
/specflow:implement或在現有 sprint 新增 bug issue。
bash .claude/scripts/doctor.sh || exit 1
bash .claude/scripts/state.sh phase "phase-cr-discuss" "spec-writer 評估 CR 影響範圍"
EXISTING=$(ls specs/changes/CR-*.md 2>/dev/null | wc -l | tr -d ' ')
CR_NUM=$((EXISTING + 1))
CR_ID="CR-$(printf '%03d' $CR_NUM)"
啟動 spec-writer 評估影響：
Agent(subagent_type="spec-writer", run_in_background=false)
input: |
這是一個 Change Request：$ARGUMENTS
請執行：
1. 讀取 specs/ 既有規格，找出受影響的 features
2. 評估影響範圍：哪些 acceptance criteria 需要新增/修改？哪些既有 e2e tests 變成回歸測試？
3. 用 AskUserQuestion 與使用者確認需求細節（含 backwards compatibility 取捨）
4. 產出 specs/changes/$CR_ID.md，包含：
- 變更描述
- 影響的 Features（清單）
- 新增的 acceptance criteria（append 到對應的 specs/features/F-XXX.md，不刪除既有 AC）
- 回歸風險評估
- 拆分為 sprint 的計畫（如果 CR 大的話可分多個 sprint）
5. 為這個 CR 建立 GitHub Milestone "Sprint N+1: $CR_ID"（N = 目前最大 sprint 編號）
6. 建立 Epic-style change issue（label: change）連結 CR 文件
bash .claude/scripts/state.sh phase "phase-cr-techlead" "tech-lead 規劃 CR 實作"
接著啟動 tech-lead → engineer + qa → verify（與 specflow:start 的 Phase 3 之後相同）：
Agent(subagent_type="tech-lead", run_in_background=true)
input: 為新建立的 milestone "Sprint N+1: $CR_ID" 拆 issue
之後 Phase 4-7 與 specflow:start 完全相同。
~~AC-X~~ 標記 + comment 註明原因（不刪除，保留歷史可追溯），並在 spec changelog 註明specs/features/archive/，並在 CR 文件記載原因確認 change label 存在（init-github.sh 會建立；若舊專案沒有，手動補）：
gh label create change --color "BFD4F2" --description "Change Request" 2>/dev/null || true
啟動完整的 specflow 專案流程。使用者只需與 spec agent 對話確認需求和架構，之後 tech-lead → (engineer + qa 並行) → verify → release 全部自動背景執行。觸發關鍵字："start", "開始", "啟動專案", "新專案"。
啟動實作流程（Lane 制：每個類型同時最多 1 個 agent）。Backend / Frontend / Pipeline 各自 1 個 engineer，加 1 個 QA、1 個 UI Designer，共最多 5 個 background agent。觸發關鍵字："implement", "實作", "開發"。
從 .specflow/state.json 讀取 SpecFlow 流程進度，重建狀態後繼續執行。在 /clear context 之後、或重開 session 時用來接續工作。觸發關鍵字："resume", "繼續", "接續"。
啟動 QA 撰寫 Playwright e2e tests。根據 spec .md 中的 acceptance criteria 撰寫 Playwright 測試，與 engineer 同時進行。觸發關鍵字："qa", "測試", "test", "e2e"。
對當前 sprint 進行三維度驗證：Completeness（完整性）、Correctness（正確性）、Coherence（一致性）。在 QA 通過後、release 前執行。觸發關鍵字："verify", "驗證", "檢查"。
更新本機 SpecFlow 安裝到 upstream 最新版。Fetch 最新 .claude/ 與 CLAUDE.md，顯示變更摘要，保留本地自訂後套用。觸發關鍵字："update", "升級", "更新 specflow"。