backfill-documentation
補充文件（Backfill Documentation）
概述
當功能已經實作完成，但沒有經過正式的設計流程時，使用此技能來補充文件。這確保所有功能都有完整的文件記錄，便於未來維護和理解。
開始時宣布： "我正在使用 backfill-documentation 技能來補充文件。"
必要子技能：
- 使用 hi-skills:brainstorming 的設計文件格式
- 使用 hi-skills:executing-plans 的實作計劃格式
流程
步驟 1：載入參考格式
先調用技能取得格式規範：
- 調用
Skill: brainstorming- 取得設計文件的格式要求 - 調用
Skill: executing-plans- 取得實作計劃的格式要求
步驟 2：收集資訊
-
識別相關 commits
git log --oneline --since="YYYY-MM-DD" --grep="<關鍵字>" -
閱讀變更的檔案
- 從 git diff 或 git show 了解變更內容
- 識別涉及的檔案和變更範圍
-
理解功能
- 這個功能解決什麼問題？
- 使用者體驗流程是什麼？
- 資料如何流動？
- 有哪些關鍵決策？
步驟 3：生成設計文件
參照 brainstorming 技能格式，建立 docs/plans/YYYY-MM-DD-<topic>-design.md：
必要元素（來自 brainstorming）：
- 概述 - 功能目的和背景
- 需求 - 明確的需求清單
- 使用者體驗流程 - ASCII 流程圖
- 資料流程 - 資料如何在系統中流動
- 資料結構變更 - 新增或修改的型別/欄位
- UI 變更 - ASCII UI 圖（如適用）
- 修改檔案清單 - 表格列出所有變更
- 實作邏輯 - 關鍵程式碼片段
- 驗收標準 - 所有項目標記為
[x]已完成
步驟 4：生成實作計劃
參照 executing-plans 技能格式，建立 docs/plans/YYYY-MM-DD-<topic>-plan.md：
必要元素（來自 executing-plans）：
- 狀態標記 -
> **狀態：** ✅ 已完成 - 目標和架構 - 簡短描述
- 任務清單 - 每個任務標記 ✅，包含：
- 檔案清單
- 完成內容
- 變更摘要 - 影響檔案和風險等級 🟢
- 相關 Commits - 列出相關的 git commits
步驟 5：建立索引檔
建立 ~/.claude/plans/YYYY-MM-DD-<project>-<topic>.md：
# <project>-<topic>
project_path: <專案路徑>
status: done
design_file: docs/plans/YYYY-MM-DD-<topic>-design.md
plan_file: docs/plans/YYYY-MM-DD-<topic>-plan.md
步驟 6：更新索引
執行 /hi-update-plans-index 更新計畫索引。
步驟 7：提交文件
git add docs/plans/
git commit -m "docs: 補充 <功能名稱> 的設計與實作計劃文件
- 新增 <topic>-design.md（設計文件）
- 新增 <topic>-plan.md（實作計劃，已完成）
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>"
設計文件範本
參照 /hi-brainstorm 輸出格式：
# <功能名稱>設計
## 概述
<簡短描述功能目的和解決的問題>
## 需求
1. <需求 1>
2. <需求 2>
3. ...
## 使用者體驗流程
┌─────────────────────────────────────────────────────────┐ │ <流程步驟> │ ├─────────────────────────────────────────────────────────┤ │ <UI 元素描述> │ └─────────────────────────────────────────────────────────┘
## 資料流程
<步驟描述> ↓ ┌──────────────────────────────────────────────────────┐ │ <元件/系統名稱> │ │ │ │ 1. <動作 1> │ │ 2. <動作 2> │ └──────────────────────────────────────────────────────┘
## 資料結構變更
### <collection/type 名稱>
```typescript
{
existingField: string;
newField: string; // 新增：說明
}
UI 變更
<ASCII UI 圖>
修改檔案清單
| 檔案 | 變更內容 |
|---|---|
path/to/file.ts |
<變更描述> |
實作邏輯
// 關鍵程式碼片段（說明核心邏輯）
驗收標準
- <標準 1>
- <標準 2>
## 實作計劃範本
參照 `/hi-ace` 輸出格式：
```markdown
# <功能名稱> 實作計劃
> **狀態：** ✅ 已完成
**目標：** <功能目標>
**架構：** <技術架構簡述>
**技術棧：** <使用的技術>
---
### 任務 1：<任務名稱> ✅
**檔案：**
- 修改：`path/to/file.ts`
**完成內容：**
- <完成的項目 1>
- <完成的項目 2>
---
### 任務 2：<任務名稱> ✅
...
---
## 變更摘要
**影響檔案：**
- `file1.ts` - <變更描述>
- `file2.ts` - <變更描述>
**整體風險：** 🟢（已完成，無問題）
**相關 Commits：**
- `<commit message 1>`
- `<commit message 2>`
記住
- 必須參照子技能 - 先調用 brainstorming 和 executing-plans 確認最新格式
- 從現有程式碼反推設計，不是編造
- 所有驗收標準標記為已完成（因為功能已實作）
- 實作計劃的任務從 git commits 推斷
- 確保文件能幫助未來的開發者理解功能
- 使用一致的格式和命名規則