spec-recorder

name	spec-recorder
description	根據本次對話的需求、調查、實作與驗證，在 doc/specs/ 產出如實工作紀錄。當使用者要求記錄 spec、整理工作紀錄、產出實作紀錄或呼叫 spec recorder 時使用。

Spec Recorder

當使用者要求使用此 skill 時，回顧本次對話中處理過的需求與實作過程，在 doc/specs/ 產出一份如實的工作紀錄檔。若使用者同時提供附加說明，視為對紀錄範圍或檔名 slug 的補充指示。

檔名規則

doc/specs/YYYY-MM-DD_<slug>.md

• 日期用今天的日期（可用 Get-Date -Format yyyy-MM-dd 取得，不要憑印象猜）。
• <slug> 為小寫 kebab-case 英文，優先以「功能代碼 + 簡短主題」組成（例：lb0017-multilingual-export-select-toast、phase6-jquery-file-input-removal）。
• 寫入前先用 rg --files 確認 doc/specs/ 內沒有同名檔案；若本次工作是延續某份既有 spec（例如分階段計畫的子任務），需在文件開頭以相對路徑引用該前案。

文件結構（必須遵守）

比照既有 spec（參考 doc/specs/2026-07-02_lb0017-multilingual-export-select-toast.md）的四大章節：

# <一句話描述本次工作的標題（繁體中文）>

（選填：若延續既有 spec / 分階段計畫，在此說明脈絡並連結前案）

## 修改內容

### 問題描述
依序列出使用者在本次對話中提出的每一個需求（含後續追加、修正的需求）。

### 修改檔案清單
| 檔案 | 異動內容 |
|------|----------|
| `src/app/...` | 簡述該檔案的異動 |

### 詳細程式碼異動
每項改動一個小節，附「修改前 / 修改後」的關鍵程式碼片段（不必貼整個檔案，
擷取足以理解差異的區塊即可）。

## 預計修改方式

依需求逐一記錄，每個需求包含三段：

**Context** — 使用者提出需求當下的情境（選取了哪段程式碼、反應了什麼現象）。
**分析** — 實際調查過程與依據（讀了哪些檔案、grep 到什麼、確認了哪些既有慣例），
只寫查證過的事實。
**修正方案** — 最後定案的做法與理由。

## 驗證方式

### 靜態驗證
實際執行過的驗證（build、grep 檢查等）與其結果，如實記錄 exit code / 錯誤訊息。

### 尚待人工驗證（建議）
列出無法在本環境自動驗證、需要人工操作確認的項目（開哪個頁面、做什麼操作、
預期看到什麼）。

## 實作紀錄

### 時間軸
依時間順序編號記錄：需求提出 → 調查 → 實作 → 驗證 → 使用者回饋 → 修正…
**包含中間走過的錯誤判斷與修正經過**，不要只留下最終正確版本。

### 經驗紀錄（給未來類似任務參考）
從本次工作萃取出可重複套用的教訓（踩到的坑、值得建立的慣例、判斷原則）。

撰寫原則

1. 如實記錄，拒絕美化：紀錄檔的價值在於保留完整決策脈絡。中途的錯誤判斷、被使用者糾正的地方、走過的彎路都要寫進「時間軸」，不要只複製最終 diff。
2. 只寫查證過的事實：所有「分析」內容必須是本次對話中實際讀檔、grep、執行指令得到的結果；沒做過的驗證不要寫成已完成，應歸入「尚待人工驗證」。
3. 記錄「為什麼」而不只是「改了什麼」：每個修正方案都要交代當下的 context 與選擇理由（為何用 A 不用 B、參考了哪個既有慣例）。
4. 語言：內文使用繁體中文；程式碼、識別字、檔名、指令保持英文。
5. 本次工作若尚未 commit/push，在時間軸最後如實註明，不要暗示已提交。

輸出

寫入檔案後，向使用者回報產出的檔案路徑與章節摘要，並提醒尚待人工驗證的項目（若有）。