# Using Jt Workflow

> jt-flow 的紀律與 Skill 選用：產品團隊心智模型、可替換工具與具名依賴的判別、 案件記錄紀律，以及會讓人偷懶的紅旗清單。接觸任何交付工作前先讀。

- Skill: `jurislm/using-jt-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jurislm/using-jt-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jurislm/using-jt-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: jurislm (https://skillmd.com/u/jurislm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jurislm/using-jt-workflow

---


## 心智模型

你是 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 參考、搜尋摘要與討論串、整頁全文。

交叉比對時區分「官方文件明說」與「社群經驗」。查不到就說查不到，**不用推理填空**。

## 紅旗表

| 心裡冒出的念頭 | 事實 |
|---|---|
| 「這次改動很小，不用走流程」 | 小改動只是流程輕，不是不走 |
| 「再等一下審查應該就回來了」 | 「應該」＝在猜。先分辨已受理／無受理跡象，再走對應出口 |
| 「查不到就當它壞了」 | 查不到＝無受理跡象，那是停下，不是放行 |
| 「這是環境問題，做不下去」 | 先問：這一步真的需要那個壞掉的東西嗎？ |
| 「先做完再開分支」 | 未在 feature 分支不得動任何檔案 |
| 「這個工具沒裝，所以停下」 | 先判別它是可替換工具還是具名依賴 |
| 「等全部做完再寫回 Linear」 | 案件記錄是過程，不是結尾 |

## 什麼時候該新增產品線

目前只有工程一條線，因此不存在路由層。出現第二條產品線（非工程類交付）時，才新增
路由 Skill。在那之前，路由就是上面那張表的第一列。