breakdown-plan

Name: breakdown-plan
Author: github

GitHub Issue 規劃與專案自動化提示詞

目標

扮演資深專案經理與 DevOps 專家，熟悉敏捷方法論與 GitHub 專案管理。你的任務是取得完整的功能產出（PRD、UX 設計、技術拆解、測試計畫），並產生一份完整的 GitHub 專案計畫，包含自動化 issue 建立、相依性連結、優先順序指派與看板式追蹤。

GitHub 專案管理最佳實務

敏捷工作項目層級

Epic：涵蓋多個功能的大型業務能力（里程碑層級）
Feature：Epic 內可交付的使用者面向功能
Story：以使用者為中心的需求，能獨立交付價值
Enabler：支援 Story 的技術基礎設施或架構工作
Test：驗證 Story 與 Enabler 的品質保證工作
Task：Story/Enabler 的實作層級工作拆解

專案管理原則

INVEST 準則：獨立、可協商、有價值、可估算、小型、可測試
就緒定義：開始工作前需有明確的驗收條件
完成定義：品質關卡與完成條件
相依性管理：明確的阻擋關係與關鍵路徑識別
價值導向優先排序：商業價值 vs. 工作量矩陣以利決策

輸入需求

使用此提示詞前，請確保擁有完整的測試工作流程產出：

核心功能文件

Feature PRD：/docs/ways-of-work/plan/{epic-name}/{feature-name}.md
技術拆解：/docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md
實作計畫：/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md

輸出格式

建立兩個主要交付物：

專案計畫：/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md
Issue 建立檢查清單：/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md

專案計畫結構

1. 專案概覽

功能摘要：簡短描述與商業價值
成功標準：可衡量的成果與 KPI
關鍵里程碑：主要交付物拆解（不含時間線）
風險評估：潛在阻礙與緩解策略

2. 工作項目層級

graph TD
    A[Epic: {Epic Name}] --> B[Feature: {Feature Name}]
    B --> C[Story 1: {User Story}]
    B --> D[Story 2: {User Story}]
    B --> E[Enabler 1: {Technical Work}]
    B --> F[Enabler 2: {Infrastructure}]

    C --> G[Task: Frontend Implementation]
    C --> H[Task: API Integration]
    C --> I[Test: E2E Scenarios]

    D --> J[Task: Component Development]
    D --> K[Task: State Management]
    D --> L[Test: Unit Tests]

    E --> M[Task: Database Schema]
    E --> N[Task: Migration Scripts]

    F --> O[Task: CI/CD Pipeline]
    F --> P[Task: Monitoring Setup]

3. GitHub Issues 拆解

Epic Issue 範本

# Epic: {Epic Name}

## Epic 描述

{Epic 摘要（來自 PRD）}

## 商業價值

- **主要目標**：{主要業務目標}
- **成功指標**：{KPI 與可衡量成果}
- **使用者影響**：{使用者如何受益}

## Epic 驗收條件

- [ ] {高階需求 1}
- [ ] {高階需求 2}
- [ ] {高階需求 3}

## 此 Epic 中的功能

- [ ] #{feature-issue-number} - {Feature Name}

## 完成定義

- [ ] 所有功能故事完成
- [ ] 端到端測試通過
- [ ] 效能基準達標
- [ ] 文件已更新
- [ ] 使用者驗收測試完成

## 標籤

`epic`, `{priority-level}`, `{value-tier}`

## 里程碑

{發行版本/日期}

## 估算

{Epic 層級 T-shirt 尺寸：XS, S, M, L, XL, XXL}

Feature Issue 範本

# Feature: {Feature Name}

## 功能描述

{功能摘要（來自 PRD）}

## 此功能中的使用者故事

- [ ] #{story-issue-number} - {User Story Title}
- [ ] #{story-issue-number} - {User Story Title}

## 技術 Enabler

- [ ] #{enabler-issue-number} - {Enabler Title}
- [ ] #{enabler-issue-number} - {Enabler Title}

## 相依性

**阻擋**：{此功能阻擋的 issue 清單}
**被阻擋**：{阻擋此功能的 issue 清單}

## 驗收條件

- [ ] {功能層級需求 1}
- [ ] {功能層級需求 2}

## 完成定義

- [ ] 所有使用者故事已交付
- [ ] 技術 Enabler 已完成
- [ ] 整合測試通過
- [ ] UX 審查已核准
- [ ] 效能測試已完成

## 標籤

`feature`, `{priority-level}`, `{value-tier}`, `{component-name}`

## Epic

#{epic-issue-number}

## 估算

{故事點數或 T-shirt 尺寸}

User Story Issue 範本

# User Story: {Story Title}

## 故事陳述

身為一個 **{使用者類型}**，我想要 **{目標}**，以便 **{效益}**。

## 驗收條件

- [ ] {具體可測試需求 1}
- [ ] {具體可測試需求 2}
- [ ] {具體可測試需求 3}

## 技術任務

- [ ] #{task-issue-number} - {實作任務}
- [ ] #{task-issue-number} - {整合任務}

## 測試需求

- [ ] #{test-issue-number} - {測試實作}

## 相依性

**被阻擋**：{必須先完成的相依性}

## 完成定義

- [ ] 驗收條件已滿足
- [ ] 程式碼審查已核准
- [ ] 單元測試已撰寫且通過
- [ ] 整合測試通過
- [ ] UX 設計已實作
- [ ] 無障礙需求已滿足

## 標籤

`user-story`, `{priority-level}`, `frontend/backend/fullstack`, `{component-name}`

## Feature

#{feature-issue-number}

## 估算

{故事點數：1, 2, 3, 5, 8}

Technical Enabler Issue 範本

# Technical Enabler: {Enabler Title}

## Enabler 描述

{支援使用者故事所需的技術工作}

## 技術需求

- [ ] {技術需求 1}
- [ ] {技術需求 2}

## 實作任務

- [ ] #{task-issue-number} - {實作細節}
- [ ] #{task-issue-number} - {基礎設施設定}

## 啟用的使用者故事

此 Enabler 支援：

- #{story-issue-number} - {故事標題}
- #{story-issue-number} - {故事標題}

## 驗收條件

- [ ] {技術驗證 1}
- [ ] {技術驗證 2}
- [ ] 效能基準達標

## 完成定義

- [ ] 實作完成
- [ ] 單元測試已撰寫
- [ ] 整合測試通過
- [ ] 文件已更新
- [ ] 程式碼審查已核准

## 標籤

`enabler`, `{priority-level}`, `infrastructure/api/database`, `{component-name}`

## Feature

#{feature-issue-number}

## 估算

{故事點數或工作量估算}

4. 優先順序與價值矩陣

優先順序	價值	條件	標籤
P0	高	關鍵路徑，阻擋發行	`priority-critical`, `value-high`
P1	高	核心功能，使用者面向	`priority-high`, `value-high`
P1	中	核心功能，內部使用	`priority-high`, `value-medium`
P2	中	重要但不阻擋	`priority-medium`, `value-medium`
P3	低	有則更好，技術債	`priority-low`, `value-low`

5. 估算指南

故事點數規模（費氏數列）

1 點：簡單變更，<4 小時
2 點：小型功能，<1 天
3 點：中型功能，1-2 天
5 點：大型功能，3-5 天
8 點：複雜功能，1-2 週
13+ 點：Epic 層級工作，需要拆解

T-Shirt 尺寸（Epic/Feature）

XS：總共 1-2 故事點數
S：總共 3-8 故事點數
M：總共 8-20 故事點數
L：總共 20-40 故事點數
XL：總共 40+ 故事點數（考慮拆解）

6. 相依性管理

graph LR
    A[Epic 規劃] --> B[功能定義]
    B --> C[Enabler 實作]
    C --> D[故事開發]
    D --> E[測試執行]
    E --> F[功能交付]

    G[基礎設施設定] --> C
    H[API 設計] --> D
    I[資料庫 Schema] --> C
    J[驗證] --> D

相依性類型

阻擋：此項完成前無法繼續的工作
相關：共享上下文但不阻擋的工作
前置條件：所需的基礎設施或設定工作
平行：可同時進行的工作

7. Sprint 規劃範本

Sprint 容量規劃

團隊速度：{每個 Sprint 的平均故事點數}
Sprint 長度：{建議 2 週 Sprint}
緩衝分配：20% 用於意外工作與錯誤修正
專注因子：70-80% 的總時間用於規劃工作

Sprint 目標定義

## Sprint {N} 目標

**主要目標**：{此 Sprint 的主要交付物}

**Sprint 中的故事**：

- #{issue} - {故事標題} ({points} 點)
- #{issue} - {故事標題} ({points} 點)

**總承諾**：{points} 故事點數
**成功標準**：{可衡量的成果}

8. GitHub 專案看板設定

欄位結構（看板）

待辦事項：已排序且準備規劃
Sprint 就緒：已詳細說明並估算，準備開發
進行中：正在處理
審查中：程式碼審查、測試或利害關係人審查
測試中：QA 驗證與驗收測試
完成：已完成且驗收

自訂欄位設定

優先順序：P0, P1, P2, P3
價值：高, 中, 低
元件：前端, 後端, 基礎設施, 測試
估算：故事點數或 T-shirt 尺寸
Sprint：目前 Sprint 指派
負責人：負責的團隊成員
Epic：父 Epic 參考

9. 自動化與 GitHub Actions

自動化 Issue 建立

name: 建立功能 Issues

on:
  workflow_dispatch:
    inputs:
      feature_name:
        description: '功能名稱'
        required: true
      epic_issue:
        description: 'Epic issue 編號'
        required: true

jobs:
  create-issues:
    runs-on: ubuntu-latest
    steps:
      - name: 建立功能 Issue
        uses: actions/github-script@v7
        with:
          script: |
            const { data: epic } = await github.rest.issues.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.inputs.epic_issue }}
            });

            const featureIssue = await github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `Feature: ${{ github.event.inputs.feature_name }}`,
              body: `# Feature: ${{ github.event.inputs.feature_name }}\n\n...`,
              labels: ['feature', 'priority-medium'],
              milestone: epic.data.milestone?.number
            });

自動化狀態更新

name: 更新 Issue 狀態

on:
  pull_request:
    types: [opened, closed]

jobs:
  update-status:
    runs-on: ubuntu-latest
    steps:
      - name: 移至審查中
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        # 將相關 issue 移至「審查中」欄位

      - name: 移至完成
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        # 將相關 issue 移至「完成」欄位

Issue 建立檢查清單

建立前準備

[ ] 功能產出完整：PRD、UX 設計、技術拆解、測試計畫
[ ] Epic 已存在：父 Epic issue 已建立，並有適當標籤與里程碑
[ ] 專案看板已設定：欄位、自訂欄位與自動化規則已設定
[ ] 團隊容量已評估：Sprint 規劃與資源分配已完成

Epic 層級 Issues

[ ] Epic issue 已建立，包含完整描述與驗收條件
[ ] Epic 里程碑已建立，包含目標發行日期
[ ] Epic 標籤已套用：epic、優先順序、價值與團隊標籤
[ ] Epic 已加入專案看板，置於適當欄位

Feature 層級 Issues

[ ] Feature issue 已建立，連結至父 Epic
[ ] 功能相依性已識別並記錄
[ ] 功能估算已完成，使用 T-shirt 尺寸
[ ] 功能驗收條件已定義，包含可衡量的成果

Story/Enabler 層級 Issues 記錄於 `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`

[ ] 使用者故事已建立，遵循 INVEST 準則
[ ] 技術 Enabler 已識別並排序優先順序
[ ] 故事點數估算已指派，使用費氏數列
[ ] 相依性已對應，在故事與 Enabler 之間
[ ] 驗收條件已詳細說明，包含可測試的需求

成功指標

專案管理 KPI

Sprint 可預測性：每個 Sprint 完成 >80% 的承諾工作
週期時間：從「進行中」到「完成」平均 <5 個工作日
前置時間：從「待辦事項」到「完成」平均 <2 週
缺陷逃逸率：<5% 的故事需要發行後修正
團隊速度：跨 Sprint 一致的故事點數交付

流程效率指標

Issue 建立時間：建立完整功能拆解 <1 小時
相依性解決時間：解決阻擋相依性 <24 小時
狀態更新準確率：>95% 自動化狀態轉換正確運作
文件完整性：100% 的 issue 具有所需範本欄位
跨團隊協作：外部相依性解決 <2 個工作日

專案交付指標

完成定義遵循度：100% 的已完成故事符合 DoD 條件
驗收條件覆蓋率：100% 的驗收條件已驗證
Sprint 目標達成率：>90% 的 Sprint 目標成功交付
利害關係人滿意度：>90% 的利害關係人核准已完成功能
規劃準確度：估算與實際交付時間差異 <10%

此全面的 GitHub 專案管理方法確保從 Epic 層級規劃到個別實作任務的完整可追溯性，並具備自動化追蹤與所有團隊成員的明確責任歸屬。

您可能也喜歡

golang-how-to

2.3Ktesting-qa

Golang 技能編排器 — 在任何 Golang 編碼、審查、除錯或設定任務中始終啟用。讀取任務上下文並從 samber/cc-skills-golang 載入最相關的技能，通常一次載入多個：撰寫 gRPC 服務時載入 golang-grpc + golang-testing + golang-error-handling；除錯 panic 時載入 golang-troubleshooting + golang-safety；稽核安全性時載入 golang-security + golang-lint + golang-safety。此外，當兩個技能看似重疊時（效能 vs 基準測試 vs 疑難排解、samber/lo vs mo vs ro、DI 叢集、安全性 vs 安全），進行消歧，並設定 CLAUDE.md 或 AGENTS.md 以在專案中強制觸發技能（/golang-how-to configure）。

samber

獲取

subagent-driven-development

233Ktesting-qa

在當前工作階段中，執行包含獨立任務的實作計畫時使用

obra

獲取

webapp-testing

153Ktesting-qa

用於與本地網頁應用程式互動及測試的工具包，使用 Playwright。支援驗證前端功能、除錯 UI 行為、擷取瀏覽器螢幕截圖及檢視瀏覽器日誌。

anthropics

獲取

繼續探索

瀏覽 testing-qa 熱門 Skills 最近更新