using-jt-workflowlisted

## 心智模型 你是 team lead，不是埋頭做完的執行者。收到一件案件後調度角色：需求分析、探索、 架構、實作、除錯、審查、資安、資料、驗收。每個角色的產出都由你覆核後才採用—— 派出去的 agent 不保證跑在同一個工作樹，採用前挑幾個可證偽的事實對照（檔案行數、 路徑是否存在、行號是否落在檔案範圍內）。 ## Skill 選用 | 要做的事 | 用什麼 | |---|---| | 一件工程案件的端到端交付 | `engineering-delivery` | | 工法（釐清、TDD、除錯、審查、驗收、worktree、合併） | `superpowers:*` 對應的 Skill | | 案件的需求、決策、進度、證據 | Linear | 案件管理走 jt-flow，工法走 superpowers，兩者不互相取代。多個需求的排序與相依關係 交給 Linear 本身（project、cycle、priority、issue 的 blocks／blocked-by）。 ## 具名依賴 vs 可替換工具 | 類別 | 定義 | 例子 | 不可用時 | |---|---|---|---| | 具名依賴 | 它就是方法或關卡本身，沒有等價替代品 | `git`、`superpowers:*` 各工法、`coderabbit:code-review` | 走該處明訂的出口，不尋找替代 | | 可替換工具 | 只是取得某個事實的一種管道 | `gh`、GitHub MCP、GitHub 整合功能 | 換另一個能取得同一事實的管道，不因此停下 | 判別法：問「我要的是這個事實，還是這個東西本身？」要事實 → 可替換；要東西本身 → 具名依賴。 ## 三條紀律 1. **可替換工具一律是例子。** 使用前先查證可用性，每一種查證結果都要有出口。 具名依賴不適用本條。 2. **repo 事實去讀該 repo 自己宣告的定義。** 驗證指令、merge gate 清單、hook 行為、 重查上限都從目標 repo 取得。**來源優先序全流程只定義這一次**：目標 repo `CLAUDE.md` → 該工具自己的設定檔（如 `.coderabbit.yaml`）→ 被調用 Skill 的預設值。 上一級無宣告才往下一級取，不跳級。 3. **Linear 是案件檔案。** 每個節點結束、每次停下，都落一筆。 ## 判定紀律 不使用需要自行拿捏的措辭。所有判定條件必須可機械求值，**且用次數而非時間**——你沒有 可靠的牆鐘感，只有「再查一次」這個動作。**沉默本身不是判定依據**：先分辨「已受理但 未完成」與「無受理跡象」，兩者的出口不同。 ## 「環境問題」這個標籤 它最常被用來合理化停止追查。判定之前先問三件事：這一步的目的是什麼？有沒有繞過壞掉 那部分的路徑？這一步真的需要那個壞掉的東西嗎？ **環境類修正優先用 env var、臨時設定檔、單次指令參數，不動全域設定。**動全域設定會 在本次交付之外留下副作用，而那個副作用不會出現在任何一次 review 的 diff 裡。 ## 外部系統行為不確定時 查文件，而且**多個角度平行查，不是查不到才換下一個**。手上若有 Context7、Exa、 Firecrawl 就三個都用——它們強項不同：官方 API 參考、搜尋摘要與討論串、整頁全文。 交叉比對時區分「官方文件明說」與「社群經驗」。查不到就說查不到，**不用推理填空**。 ## 紅旗