| name | cheat-spec |
| description | 把用戶口述的任務需求、學習目標或開發功能，整理成 cheat-predict 可讀的標準規格文件，存入 scripts/。觸發詞："幫我整理規格"/"把需求存成規格"/"寫 spec"/"啟動任務前先存規格"/"我要做 [某功能/任務/學習目標]"。與 cheat-predict 搭配：cheat-spec 負責收集需求並落盤，cheat-predict 讀規格做盲預測。只要用戶描述了具體任務並想啟動 cheat-on-content 流程，就應使用此 skill。 |
| allowed-tools | Read, Write, Bash |
/cheat-spec — 需求 → 標準規格文件
把用戶描述的需求整理成結構化規格文件，供 cheat-predict 讀取、打分和預測。
規格文件的品質直接決定預測的精度。一份好的規格要讓 cheat-predict 能清楚評估三件事：任務範圍有多大、技術複雜度在哪、怎麼知道做完了。這個 skill 的責任是確保這三點都有足夠資訊。
Overview
[用戶描述需求]
↓
[Phase 0: 讀 .cheat-state.json，確認 domain 和狀態]
↓
[Phase 1: 分析已有信息，一問一答補齊缺口]
↓
[Phase 2: 起草規格，展示給用戶 review]
↓
[Phase 3: 用戶確認或修改]
↓
[Phase 4: 計算內容 hash，落盤到 scripts/]
↓
[Phase 5: 提示下一步]
Phase 0: 讀狀態
讀用戶當前工作目錄的 .cheat-state.json。
- 不存在 → 停止：「未找到 .cheat-state.json，請先跑 /cheat-init 初始化項目。」
- 存在 → 讀取
content_form（daily-work | daily-learning | ai-coding）
Phase 1: 需求收集
先分析用戶已給的信息，不重複問已有答案的問題。根據 content_form 判斷哪些「必要欄位」還缺。
必要欄位（依 domain）
ai-coding：
| 欄位 | 說明 |
|---|
| 功能描述 | 做什麼，一句話說清楚 |
| 驗收標準 | 至少 1 條可操作、可測試的完成條件 |
| 技術依賴 | 語言、主要庫、運行環境 |
| 邊界條件 | 已知難點、約束或 edge case（可選，但值得問一次） |
daily-work：
| 欄位 | 說明 |
|---|
| 任務描述 | 做什麼 |
| 交付物 | 完成後產出什麼 |
| 截止時間或預估耗時 | 時間維度 |
daily-learning：
| 欄位 | 說明 |
|---|
| 學習主題 | 學什麼 |
| 當前水平 | 從哪個起點出發 |
| 學習目標 | 學完後能做什麼（可測試的） |
| 應用 / 驗證方式 | 怎麼知道真的學會了 |
問問題規則
- 一次只問一個問題
- 已從用戶描述中提取到的欄位，不要重複問
- 最多問 3 輪；邊界條件等軟性欄位若用戶未提，留空並標「（用戶未提供）」，不要強求
- 若用戶初始描述已包含所有必要欄位 → 直接進 Phase 2，不問問題
Phase 2: 起草規格
根據收集到的信息，按對應 domain 的格式起草規格文件，展示給用戶 review：
ai-coding 格式
# <功能名稱（3-8 字）>
## 目標
<一句話：做什麼，以及為什麼做>
## 驗收標準
- <標準 1：可操作、可測試>
- <標準 2>
## 技術依賴
- 語言/框架：<...>
- 主要庫：<...>
- 環境約束：<...>（Windows、Python 版本、API 限制等）
## 邊界條件 / 已知風險
- <已知難點或 edge case>（若無，此段省略）
## 預估時長
<用戶給的或從描述推斷>
daily-work 格式
# <任務名稱>
## 任務描述
<具體要做什麼>
## 交付物
<完成後產出什麼，格式是什麼>
## 背景與約束
<受眾、工具、限制條件>
## 截止時間 / 預估耗時
<...>
## 驗收標準
- <怎麼知道任務完成了>
daily-learning 格式
# <學習主題>
## 學習目標
<學完後能做什麼，可測試的>
## 當前起點
<現在對這個主題的掌握程度>
## 學習計劃
<打算怎麼學：資源、步驟、時長>
## 應用 / 驗證方式
<怎麼知道真的學會了>
## 預估時長
<...>
起草後輸出：
這是規格草稿，請 review：
[草稿內容]
回 "ok" 直接存檔，或告訴我要修改哪裡。
Phase 3: 用戶確認
- 「ok」/ 「好」/ 「可以」→ 進 Phase 4
- 用戶指出修改 → 更新對應字段 → 重新展示 → 循環
Phase 4: 落盤
- 確定最終規格內容（純文字字串）
- 用 Bash 計算 id：
python -c "import hashlib,sys; print(hashlib.sha256(sys.stdin.read().encode()).hexdigest()[:12])" 並把內容 pipe 進去
- 生成
short：從標題取 3-5 個字，去標點，空格換底線（中英皆可）
- 今天日期：
python -c "from datetime import date; print(date.today())"
- 文件名：
scripts/YYYY-MM-DD_<id>_<short>.md
- 用 Write 工具存入
scripts/
Phase 5: 提示下一步
✅ 規格已存：scripts/YYYY-MM-DD_<id>_<short>.md
下一步：
啟動預測 scripts/YYYY-MM-DD_<id>_<short>.md
Key Rules
- 不編造沒有的信息：用戶未提供的邊界條件，標「（用戶未提供）」，不要猜測填入
- 不跳過 review：落盤前必須展示草稿讓用戶確認
- id 從內容算：不要用時間戳或隨機值替代——cheat-predict 靠 id 做跨文件追溯
- scripts/ 必須存在：若目錄不存在，提示用戶先跑 /cheat-init（它會建好目錄結構）
