/sdlc:ticket-check — 金魚閘門

建完票、動手寫程式之前，跑這個。參數是 story 編號（例 /sdlc:ticket-check 361）。

先讀 docs/agents/sdlc.md 拿 issue repo。

為什麼

做法取自 elephant-goldfish：

Goldfish receives only what you hand it… It has no idea what you've been thinking. That's the point.

寫票的人腦子裡有整段對話——裁示、查過的程式碼、被否決的選項。票寫得再糊， 自己讀起來都通順，因為缺的部分腦補得出來。而真正要讀那張票的是 沒有那段對話的人：壓縮後的你、下一個 session、或批准者自己。

怎麼做

1. gh issue view 取出 story 底下每一張 task 的完整 body

2. 開一個 general-purpose subagent，只給它票的內容

   ⚠️ 不要給對話脈絡、不要解釋理由、不要說哪裡你覺得寫得不錯。 一句「這是我們討論後的結論」就毀掉整件事——它的無知才是工具。

3. 要它回三件事：

   	問什麼	用途
   Comprehension	用你自己的話說：每張票要做什麼、為什麼	只是資訊。但複述錯了 = 票沒寫清楚
   Critic	哪裡矛盾、缺漏、含糊？哪些 AC 驗不出來？相依順序對嗎？	閘門
   Readiness	能不能不問任何問題就開始實作？不能的話缺什麼？	閘門

4. Critic 有阻擋性發現、或 Readiness 不通過 → 改票，重跑。
5. 最多三輪。 三輪還過不了，不是票寫得不好，是規格本身不足—— 停下來回報批准者，不要自己補。

判準

不是「找不出任何毛病」——那永遠達不到。是這兩題都答得出「是」：

• 一個沒有對話脈絡的人，讀完知道要做什麼嗎？
• 他知道做完要怎麼證明做對了嗎？

什麼時候可以跳過

• 純文件變更
• 已走過一輪、只是把某張票拆得更細

缺陷票不跳過——缺陷票最常見的病是前提本身沒查證， 而「你怎麼知道會這樣？」正是金魚會問、寫票的人不會問自己的那一題。