sprint-planning

name	sprint-planning
description	Use when the user wants to conduct or prepare for a Sprint planning session — organizing ticket candidates, reviewing capacity, or preparing a release page. Trigger: 'sprint planning', 'sprint 規劃', '下個 sprint', '排 sprint', 'release page'.
metadata	{"author":"Polaris","version":"1.0.0"}

Sprint Planning — Sprint 規劃討論引導

引導 Sprint Planning 討論：從 JIRA 拉取候選 tickets，計算 capacity，偵測 carry-over，建議優先排序，來回討論後產出最終 sprint backlog。可選推送 Confluence Release page。

定位：自動化確定性部分（拉 JIRA、算點數、排依賴），討論決策留給使用者。這不是一鍵產出工具，而是互動式的規劃助手。 它可以產 planning / release page artifact，但不得把 planning artifact 當成 author-side release authority；是否 release_eligible / release_completed 仍必須由 shared gates 決定。

前置：讀取 workspace config

讀取 workspace config（參考 references/workspace-config-reader.md）。 本步驟需要的值：jira.instance、jira.projects（取得 project keys 用於 JQL）、confluence.space、scrum.sprint_capacity。 若 config 不存在，使用 references/shared-defaults.md 的 fallback 值。

Defaults

參數	預設值	說明
Sprint capacity	20 pts （config: scrum.sprint_capacity）	使用者的個人容量
Sprint duration	10 working days	2 weeks
Projects	（config: jira.projects[].key）	從 workspace-config.yaml 讀取
Confluence space	（config: confluence.space）	Release page 所在空間

Workflow

1. Collect inputs

兩種方式取得候選 tickets：

方式 A — 使用者提供 ticket keys： 使用者直接給一組 ticket keys（如 PROJ-500 PROJ-501 TEAM-3300），從 JIRA 拉取每張的資訊。

方式 B — 從 JIRA board 自動拉取： 搜尋使用者可能的候選：

mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql
  cloudId: {config: jira.instance}  # fallback: your-domain.atlassian.net
  jql: assignee = currentUser() AND status not in ("已釋出", "已關閉", "完成", "PENDING") AND project in ({config: jira.projects[].key}) ORDER BY priority DESC, updated DESC
  fields: ["summary", "status", "issuetype", "priority", "story_points", "sprint"]
  maxResults: 30

詢問使用者要用哪種方式，或者兩者結合（自動拉 + 使用者補充）。

2. Fetch ticket details

對每張候選 ticket 拉取完整資訊：

mcp__claude_ai_Atlassian__getJiraIssue
  cloudId: {config: jira.instance}  # fallback: your-domain.atlassian.net
  issueIdOrKey: <TICKET-KEY>

收集：

• Key + 標題
• Issue type（Epic / Story / Task / Bug / Sub-task）
• Status（判斷 carry-over vs 新單）
• Priority
• Story points（如果已估點）
• Sprint（判斷是否已在某個 sprint 中）
• Links（判斷依賴關係：blocks / is blocked by）
• Epic link（歸屬哪個 Epic）

3. Detect carry-overs

Carry-over = 上個 sprint 未完成的單。判定條件：

• 在前一個 sprint 中（sprint 欄位）
• 狀態不是 已釋出 / 完成 / 已關閉

Carry-over 在排序時有更高優先權（已經開始的工作應該先完成）。

標記每張 carry-over ticket 的當前進度：

• IN DEVELOPMENT → 開發中，需繼續
• CODE REVIEW → PR 等待 review
• WAITING FOR QA → 等 QA
• 其他 → 標註狀態

4. Sort & suggest

用以下規則產出建議排序：

1. Carry-over 最優先（已投入成本，sunk cost 最小化）
2. P0 / Highest priority 次之
3. 有依賴關係的 tickets 考慮順序：被 block 的排在 blocker 之後
4. 已估點的 優先於未估點的（未估點的需要先估）
5. 同優先級按 Epic 分組（同 Epic 的單盡量排一起）

5. Present planning table

以表格呈現，讓使用者快速掌握全局：

## Sprint Planning — Sprint YYYY.MM.DD

**Capacity**: 20 pts | **候選總點數**: XX pts | **差額**: ±Y pts

### Carry-over（上個 sprint 未完成）

| # | Ticket | Title | Type | Status | Points | Priority | Notes |
|---|--------|-------|------|--------|--------|----------|-------|
| 1 | PROJ-100 | feature title A | Story | CODE REVIEW | 3 | Medium | PR 等 review |
| 2 | PROJ-200 | bug title B | Bug | WAITING FOR QA | 2 | High | 等 QA |

小計：5 pts

### 新增候選

| # | Ticket | Title | Type | Points | Priority | Epic | Dependency | Notes |
|---|--------|-------|------|--------|----------|------|------------|-------|
| 3 | PROJ-500 | xxx | Story | 5 | High | PROJ-400 | — | |
| 4 | PROJ-501 | yyy | Task | 3 | Medium | PROJ-400 | blocked by PROJ-500 | |
| 5 | TEAM-3400 | zzz | Bug | ? | High | — | — | 未估點 |

小計：8+ pts

### 總計

| 項目 | 點數 |
|------|------|
| Carry-over | 5 |
| 新增候選 | 8+ |
| **合計** | **13+** |
| Capacity | 20 |
| **剩餘** | **7-** |

附加提示：

• 未估點的 tickets 用 ? 標示，提醒需要先估點
• 超過 capacity 時標紅警告
• 依賴關係用箭頭標示（blocked by PROJ-500）

6. Interactive discussion

呈現表格後進入討論模式：

使用者可能的操作：

• 「移除 #5」→ 從候選中移除
• 「加入 PROJ-600」→ 新增到候選，拉 JIRA 資訊後更新表格
• 「PROJ-500 改 3 點」→ 調整估點
• 「PROJ-501 排到 PROJ-500 後面」→ 調整順序
• 「這個 sprint 我有 2 天請假」→ 調整 capacity（20 → 16 pts）
• 「OK」/ 「確定」→ 鎖定最終版本

每次調整後重新計算總點數和差額，更新表格呈現。

Guardrails：

• 總點數超過 capacity 10% 以上時主動提醒
• 有未估點的 tickets 時提醒需要先估點（可觸發 breakdown）
• 有依賴衝突時（如 A blocks B 但 B 排在 A 前面）主動提醒

7. Generate Release page draft (optional)

使用者確認最終 sprint backlog 後，詢問是否產出 Confluence Release page。

如果使用者同意：

Step 7a — 計算 Release 日期： Sprint 結束日 = Sprint 開始日 + 10 working days。Release page 標題格式：Release YYYYMMDD。 詢問使用者確認日期（可能因假期調整）。

Step 7b — 格式化 Release page：

依照現有 Release page 格式（markdown bullet list，按團隊分組）：

* Team A

    * [PROJ-100 ticket title](https://{config: jira.instance}/browse/PROJ-100) — Code Review
    * [PROJ-101 ticket title](https://{config: jira.instance}/browse/PROJ-101) — 開放

* Team B

    * [PROJ-200 ticket title](https://{config: jira.instance}/browse/PROJ-200) — Waiting for QA

每張 ticket 附上當前狀態。已關閉的用 ~~刪除線~~。

Release page 是 planning / communication artifact，不是 release gate。頁面出現某張 ticket， 不代表該 ticket 已達 release_eligible，更不代表 release_completed。

Step 7c — 推送 Confluence：

Workspace language policy gate（blocking）：完整規則見 references/workspace-language-policy.md。Release page / planning summary 寫入 Confluence 前，先把最終內容落成 temp markdown，執行：

bash scripts/validate-language-policy.sh --blocking --mode artifact <sprint-planning-release-page.md>

exit ≠ 0 → 修正頁面主敘述語言後重跑；不可把未通過 gate 的 release page 寫入 Confluence。

依 references/confluence-page-update.md 的簡化模式：搜尋 Release page（CQL title = "Release YYYYMMDD"），已存在則更新，不存在則建立。更新完成後附上 Confluence 頁面連結。

Do

• 優先排 carry-over（已投入成本的工作）
• 即時重算點數和差額，每次調整後更新
• 依賴關係衝突時主動提醒
• 未估點 tickets 提醒需要先估
• Release page 格式嚴格遵循現有頁面風格
• 支持多輪來回討論，不急著鎖定

Don't

• 不要自動決定 sprint 內容 — 排序是建議，決定權在使用者
• 不要未經確認就推 Confluence
• 不要把不屬於使用者的 tickets 加進來（除非使用者指定）
• 不要忽略 capacity 超標 — 必須明確提醒
• 不要在討論中途跳到其他 skill（如使用者說「PROJ-500 估幾點」可以建議觸發估點 skill，但不要自動觸發）

Prerequisites

• Atlassian MCP 已連線（JIRA + Confluence）
• 使用者了解當前 sprint 狀態（或從 JIRA board 拉取）

Post-Task Reflection (required)

Non-optional. Execute before reporting task completion.

Run the checklist in post-task-reflection-checkpoint.md.