backfill-documentation

Original：🇨🇳 Chinese

Translated

Used when a feature has been implemented but lacks design documentation and implementation plans. Automatically generate documents conforming to /hi-brainstorm and /hi-ace formats based on existing code and git history.

1installs

Sourcejimmy1987s/ec-claude-skills

Added on2026-04-04

NPX Install

npx skill4agent add jimmy1987s/ec-claude-skills backfill-documentation

SKILL.md Content (Chinese)

View Translation Comparison →

Backfill Documentation

Overview

Use this skill to supplement documents when a feature has been implemented without going through a formal design process. This ensures that all features have complete documentation records for future maintenance and understanding.

Announce at start: "I am using the backfill-documentation skill to supplement documents."

Required sub-skills:

Use the design document format of hi-skills:brainstorming
Use the implementation plan format of hi-skills:executing-plans

Procedure

Step 1: Load reference formats

Call skills first to obtain format specifications:

Call
```
Skill: brainstorming
```
- Get format requirements for design documents
Call
```
Skill: executing-plans
```
- Get format requirements for implementation plans

Step 2: Collect information

Identify relevant commits

bash

git log --oneline --since="YYYY-MM-DD" --grep="<關鍵字>"

Read changed files
- Understand changes from git diff or git show
- Identify involved files and scope of changes
Understand the feature
- What problem does this feature solve?
- What is the user experience flow?
- How does data flow?
- What are the key decisions?

Step 3: Generate design document

Refer to the format of the brainstorming skill, create

docs/plans/YYYY-MM-DD-<topic>-design.md

:

Required elements (from brainstorming):

Overview - Feature purpose and background
Requirements - Clear list of requirements
User experience flow - ASCII flow chart
Data flow - How data flows in the system
Data structure changes - New or modified types/fields
UI changes - ASCII UI diagram (if applicable)
List of modified files - Table listing all changes
Implementation logic - Key code snippets
Acceptance criteria - All items marked as
```
[x]
```
completed

Step 4: Generate implementation plan

Refer to the format of the executing-plans skill, create

docs/plans/YYYY-MM-DD-<topic>-plan.md

:

Required elements (from executing-plans):

Status tag -
```
> **狀態：** ✅ 已完成
```
Goals and architecture - Short description
Task list - Each task marked ✅, including:
- List of files
- Completed content
Change summary - Affected files and risk level 🟢
Relevant Commits - List relevant git commits

Step 5: Create index file

Create

~/.claude/plans/YYYY-MM-DD-<project>-<topic>.md

:

markdown

# <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

Step 6: Update index

Run

/hi-update-plans-index

to update the plan index.

Step 7: Commit documents

bash

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>"

Design Document Template

Refer to the /hi-brainstorm output format:

markdown

# <功能名稱>設計

## 概述

<簡短描述功能目的和解決的問題>

## 需求

1. <需求 1>
2. <需求 2>
3. ...

## 使用者體驗流程

┌─────────────────────────────────────────────────────────┐ │ <流程步驟> │ ├─────────────────────────────────────────────────────────┤ │ <UI 元素描述> │ └─────────────────────────────────────────────────────────┘


## 資料流程

<步驟描述> ↓ ┌──────────────────────────────────────────────────────┐ │ <元件/系統名稱> │ │ │ │ 1. <動作 1> │ │ 2. <動作 2> │ └──────────────────────────────────────────────────────┘


## 資料結構變更

### <collection/type 名稱>

```typescript
{
  existingField: string;
  newField: string;  // 新增：說明
}

UI 變更

修改檔案清單

檔案	變更內容
`path/to/file.ts`	<變更描述>

實作邏輯

typescript

// 關鍵程式碼片段（說明核心邏輯）

驗收標準

<標準 1>
<標準 2>


## Implementation Plan Template

Refer to the /hi-ace output format:

```markdown
# <功能名稱> 實作計劃

> **狀態：** ✅ 已完成

**目標：** <功能目標>

**架構：** <技術架構簡述>

**技術棧：** <使用的技術>

---

### 任務 1：<任務名稱> ✅

**檔案：**
- 修改：`path/to/file.ts`

**完成內容：**
- <完成的項目 1>
- <完成的項目 2>

---

### 任務 2：<任務名稱> ✅

...

---

## 變更摘要

**影響檔案：**
- `file1.ts` - <變更描述>
- `file2.ts` - <變更描述>

**整體風險：** 🟢（已完成，無問題）

**相關 Commits：**
- `<commit message 1>`
- `<commit message 2>`

Remember

Must refer to sub-skills - Call brainstorming and executing-plans first to confirm the latest format
Infer design from existing code, do not fabricate
All acceptance criteria are marked as completed (since the feature has been implemented)
Tasks in the implementation plan are inferred from git commits
Ensure that documents can help future developers understand the feature
Use consistent format and naming rules