create-implementation-plan

建立實作計畫

主要指令

你的目標是為 ${input:PlanPurpose} 建立一個新的實作計畫檔案。你的輸出必須是機器可讀、確定性且結構化，以供其他 AI 系統或人類自主執行。

執行上下文

此提示專為 AI 對 AI 通訊及自動化處理設計。所有指示必須按字面解釋，並系統性地執行，無需人類解讀或釐清。

核心需求

• 產生可由 AI 代理或人類完全執行的實作計畫
• 使用確定性語言，零模糊性
• 所有內容結構化以利自動解析與執行
• 確保完全自包含，無需外部依賴即可理解

計畫結構需求

計畫必須由離散的、原子化的階段組成，每個階段包含可執行的任務。每個階段必須可由 AI 代理或人類獨立處理，除非明確宣告跨階段依賴。

階段架構

• 每個階段必須有可衡量的完成標準
• 除非指定依賴關係，階段內的任務應可並行執行
• 所有任務描述必須包含具體的檔案路徑、函式名稱及確切的實作細節
• 不應有任何任務需要人類解讀或決策

AI 最佳化實作標準

• 使用明確、無歧義的語言，無需解讀
• 所有內容以機器可解析格式（表格、列表、結構化資料）呈現
• 包含具體的檔案路徑、行號及確切的程式碼參考（如適用）
• 明確定義所有變數、常數及設定值
• 每個任務描述中提供完整的上下文
• 使用標準化前綴作為所有識別碼（REQ-、TASK- 等）
• 包含可自動驗證的驗證標準

輸出檔案規格

• 將實作計畫檔案儲存在 /plan/ 目錄
• 使用命名慣例：[purpose]-[component]-[version].md
• 目的前綴：upgrade|refactor|feature|data|infrastructure|process|architecture|design
• 範例：upgrade-system-command-4.md、feature-auth-module-1.md
• 檔案必須是有效的 Markdown，並包含正確的 front matter 結構

強制範本結構

所有實作計畫必須嚴格遵循以下範本。每個區段都是必需的，且必須填入具體、可操作的內容。AI 代理必須在執行前驗證範本符合性。

範本驗證規則

• 所有 front matter 欄位必須存在且格式正確
• 所有區段標題必須完全相符（區分大小寫）
• 所有識別碼前綴必須遵循指定格式
• 表格必須包含所有必要欄位
• 最終輸出中不得保留任何佔位文字
• 識別碼必須唯一宣告。 每個識別碼（REQ-NNN、SEC-NNN、CON-NNN、GUD-NNN、PAT-NNN、GOAL-NNN、TASK-NNN、ALT-NNN、DEP-NNN、FILE-NNN、TEST-NNN、RISK-NNN、ASSUMPTION-NNN）必須恰好宣告一次。宣告是指識別碼引入一行的情況：TASK/GOAL 表格行中的第一個儲存格，或項目符號行中粗體前綴如 - **REQ-001**: ...。同一個識別碼之後可以在計畫中任何地方作為參考出現多次（例如 TASK 主體引用 REQ、一個 TASK 引用另一個 TASK、Dependencies 區段指向已在前面宣告的 DEP 等）。參考是預期的，不視為衝突。

識別碼唯一性檢查

在最終確定計畫前執行這些檢查。檢查 (1) 和 (2) 針對宣告，必須回傳零行。檢查 (3) 是廣泛的資訊掃描：它也會顯示有效的參考，因此僅供參考，不作為門檻。

# 設定 PLAN_FILE 為要驗證的計畫。
PLAN_FILE="/plan/<purpose>-<component>-<version>.md"

# 1) 表格行中重複的 TASK / GOAL 宣告。
grep -oE '\| (TASK|GOAL)-[0-9]+ \|' "$PLAN_FILE" \
  | sed -E 's/.*((TASK|GOAL)-[0-9]+).*/\1/' \
  | sort | uniq -d

# 2) 項目符號規格行中重複的宣告 ID。
grep -oE '^- \*\*(REQ|SEC|CON|GUD|RISK|ASSUMPTION|TASK|GOAL|FILE|TEST|PAT|ALT|DEP)-[0-9]+\*\*:' "$PLAN_FILE" \
  | sed -E 's/^- \*\*([A-Z]+-[0-9]+)\*\*:.*/\1/' \
  | sort | uniq -d

# 3) 廣泛的重複掃描（僅供診斷；可能包含有效的參考）。
grep -oE '(REQ|SEC|CON|GUD|RISK|ASSUMPTION|TASK|GOAL|FILE|TEST|PAT|ALT|DEP)-[0-9]+' "$PLAN_FILE" \
  | sort | uniq -d

先決條件：支援 POSIX 的 shell（sh / bash），並包含 grep、sed、sort 和 uniq。在沒有這些工具的 Windows 上，請使用等效的平台原生指令，並保留相同的宣告與參考邏輯。

如果檢查 (1) 或 (2) 回傳任何行，請重新編號重複的識別碼，使每個識別碼恰好宣告一次，然後重新執行檢查，直到兩者皆為空。

狀態

實作計畫的狀態必須在 front matter 中明確定義，並反映計畫的當前狀態。狀態可以是以下之一（狀態顏色在括號中）：Completed（亮綠色徽章）、In progress（黃色徽章）、Planned（藍色徽章）、Deprecated（紅色徽章）或 On Hold（橘色徽章）。它也應在簡介區段中以徽章顯示。

---
goal: [描述套件實作計畫目標的簡潔標題]
version: [可選：例如 1.0、日期]
date_created: [YYYY-MM-DD]
last_updated: [可選：YYYY-MM-DD]
owner: [可選：負責此規格的團隊/個人]
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
tags: [可選：相關標籤或分類列表，例如 `feature`、`upgrade`、`chore`、`architecture`、`migration`、`bug` 等]
---

# 簡介

![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)

[對計畫及其目標的簡短介紹。]

## 1. 需求與限制

[明確列出所有影響計畫並限制其實作方式的需求與限制。使用項目符號或表格以利清晰。]

- **REQ-001**: 需求 1
- **SEC-001**: 安全需求 1
- **[3 字母]-001**: 其他需求 1
- **CON-001**: 限制 1
- **GUD-001**: 指引 1
- **PAT-001**: 遵循的模式 1

## 2. 實作步驟

### 實作階段 1

- GOAL-001: [描述此階段的目標，例如「實作功能 X」、「重構模組 Y」等]

| 任務 | 描述 | 已完成 | 日期 |
|------|------|--------|------|
| TASK-001 | 任務 1 的描述 | ✅ | 2025-04-25 |
| TASK-002 | 任務 2 的描述 | |  |
| TASK-003 | 任務 3 的描述 | |  |

### 實作階段 2

- GOAL-002: [描述此階段的目標，例如「實作功能 X」、「重構模組 Y」等]

| 任務 | 描述 | 已完成 | 日期 |
|------|------|--------|------|
| TASK-004 | 任務 4 的描述 | |  |
| TASK-005 | 任務 5 的描述 | |  |
| TASK-006 | 任務 6 的描述 | |  |

## 3. 替代方案

[考慮過但未選擇的替代方法列表，以提供所選方法的背景與理由。]

- **ALT-001**: 替代方案 1
- **ALT-002**: 替代方案 2

## 4. 依賴項目

[列出需要處理的依賴項目，例如計畫依賴的函式庫、框架或其他元件。]

- **DEP-001**: 依賴項目 1
- **DEP-002**: 依賴項目 2

## 5. 檔案

[列出將受功能或重構任務影響的檔案。]

- **FILE-001**: 檔案 1 的描述
- **FILE-002**: 檔案 2 的描述

## 6. 測試

[列出需要實作以驗證功能或重構任務的測試。]

- **TEST-001**: 測試 1 的描述
- **TEST-002**: 測試 2 的描述

## 7. 風險與假設

[列出與計畫實作相關的風險或假設。]

- **RISK-001**: 風險 1
- **ASSUMPTION-001**: 假設 1

## 8. 相關規格 / 延伸閱讀

[連結至相關規格 1]
[連結至相關外部文件]