| 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(它會建好目錄結構)