원클릭으로 Manus에서 모든 스킬 실행

specflow-change

스타5

포크1

업데이트2026년 5월 8일 16:56

為已完成的專案新增需求變更（Change Request）。spec-writer 評估影響範圍 → 建立 CR 文件 + 新 Sprint milestone → 走原本的 tech-lead → engineer + qa → verify 流程。觸發關鍵字："change", "新需求", "需求變更", "CR", "後續功能", "新增功能"。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

gpwork4u

gpwork4u/specflow

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Change Request 流程（專案完成後新增需求）

當專案已 release 但需要新增/修改功能時，用這個流程。不是改 spec 重來，而是把變更當作新的迭代層疊上去，並透過既有 e2e tests 自動形成回歸測試。

何時使用

既有專案已完成第一輪 Sprint，使用者想新增功能
既有功能行為需要調整（不是 bug fix）
對外部依賴 / API contract 的變更

Bug fix 不要用這個流程，直接 /specflow:implement 或在現有 sprint 新增 bug issue。

流程

Step 0：環境檢查與 state 紀錄

bash .claude/scripts/doctor.sh || exit 1
bash .claude/scripts/state.sh phase "phase-cr-discuss" "spec-writer 評估 CR 影響範圍"

Step 1：找出 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)"

Step 2：spec-writer 互動討論（前景）

啟動 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 文件

Step 3：確認 spec-writer 產出後，走標準流程

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 完全相同。

既有 acceptance criteria 的處理規則

新增 AC → append 到既有 F-XXX.md 檔尾。既有 AC 保留 = 自動回歸測試
修改既有行為 → 在 .md 加新的 AC，描述新行為；舊的 AC 如果不再合法，用刪除線 ~~AC-X~~ 標記 + comment 註明原因（不刪除，保留歷史可追溯），並在 spec changelog 註明
完全移除功能 → 移到 specs/features/archive/，並在 CR 文件記載原因

為什麼這樣設計

Source of truth 仍是 specs/features/*.md，CR 文件只是 changelog
**既有 AC 不刪 = QA 不會刪對應 e2e test = 回歸測試自動覆蓋
沿用 sprint 流程，無需學新工具或新概念
可累積：CR-001、CR-002... 一路加上去，每個都是獨立可驗證的迭代

需要新 label

確認 change label 存在（init-github.sh 會建立；若舊專案沒有，手動補）：

gh label create change --color "BFD4F2" --description "Change Request" 2>/dev/null || true

이 저장소의 다른 Skills

같은 저장소

specflow-start

gpwork4u/specflow

啟動完整的 specflow 專案流程。使用者只需與 spec agent 對話確認需求和架構，之後 tech-lead → (engineer + qa 並行) → verify → release 全部自動背景執行。觸發關鍵字："start", "開始", "啟動專案", "新專案"。

2026-05-225

specflow-implement

gpwork4u/specflow

啟動實作流程（Lane 制：每個類型同時最多 1 個 agent）。Backend / Frontend / Pipeline 各自 1 個 engineer，加 1 個 QA、1 個 UI Designer，共最多 5 個 background agent。觸發關鍵字："implement", "實作", "開發"。

2026-05-215

specflow-resume

gpwork4u/specflow

從 .specflow/state.json 讀取 SpecFlow 流程進度，重建狀態後繼續執行。在 /clear context 之後、或重開 session 時用來接續工作。觸發關鍵字："resume", "繼續", "接續"。

2026-05-195

specflow-qa

gpwork4u/specflow

啟動 QA 撰寫 Playwright e2e tests。根據 spec .md 中的 acceptance criteria 撰寫 Playwright 測試，與 engineer 同時進行。觸發關鍵字："qa", "測試", "test", "e2e"。

2026-05-085

specflow-verify

gpwork4u/specflow

對當前 sprint 進行三維度驗證：Completeness（完整性）、Correctness（正確性）、Coherence（一致性）。在 QA 通過後、release 前執行。觸發關鍵字："verify", "驗證", "檢查"。

2026-05-085

specflow-update

gpwork4u/specflow

更新本機 SpecFlow 安裝到 upstream 最新版。Fetch 最新 .claude/ 與 CLAUDE.md，顯示變更摘要，保留本地自訂後套用。觸發關鍵字："update", "升級", "更新 specflow"。

2026-05-085

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	[變更描述]

Change Request 流程（專案完成後新增需求）

何時使用

既有專案已完成第一輪 Sprint，使用者想新增功能
既有功能行為需要調整（不是 bug fix）
對外部依賴 / API contract 的變更

Bug fix 不要用這個流程，直接 /specflow:implement 或在現有 sprint 新增 bug issue。

流程

Step 0：環境檢查與 state 紀錄

bash .claude/scripts/doctor.sh || exit 1
bash .claude/scripts/state.sh phase "phase-cr-discuss" "spec-writer 評估 CR 影響範圍"

Step 1：找出 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)"

Step 2：spec-writer 互動討論（前景）

啟動 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 文件

Step 3：確認 spec-writer 產出後，走標準流程

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 完全相同。

既有 acceptance criteria 的處理規則

新增 AC → append 到既有 F-XXX.md 檔尾。既有 AC 保留 = 自動回歸測試
修改既有行為 → 在 .md 加新的 AC，描述新行為；舊的 AC 如果不再合法，用刪除線 ~~AC-X~~ 標記 + comment 註明原因（不刪除，保留歷史可追溯），並在 spec changelog 註明
完全移除功能 → 移到 specs/features/archive/，並在 CR 文件記載原因

為什麼這樣設計

Source of truth 仍是 specs/features/*.md，CR 文件只是 changelog
**既有 AC 不刪 = QA 不會刪對應 e2e test = 回歸測試自動覆蓋
沿用 sprint 流程，無需學新工具或新概念
可累積：CR-001、CR-002... 一路加上去，每個都是獨立可驗證的迭代

需要新 label

確認 change label 存在（init-github.sh 會建立；若舊專案沒有，手動補）：

gh label create change --color "BFD4F2" --description "Change Request" 2>/dev/null || true