Develop

/develop — Dev Flow 的第一棒

Ticket → **分支 → 實作 → commit** → /simplify → /code-review → PR

這支 skill 只負責粗體那三段。不 push、不開 PR、不 merge。

檢查清單

開工時用 TaskCreate 建下列項目，逐項推進：

1. 解析 ticket，寫出一句可驗收的完成條件
2. 同步基底分支並切出新分支
3. 讀既有程式碼，決定改動範圍
4. 實作 + 跑既有 lint/test
5. Conventional commit（不 push）
6. 交棒給 /simplify

Step 1 — 解析 ticket

$ARGUMENTS 是純數字 → 當作 issue 編號：

gh issue view $ARGUMENTS --json number,title,body,labels,url

否則當作需求描述文字。

沒有 ticket 時：不要停下來，但要提醒一句「這次沒有票，之後追不回改動原因」，並提議 gh issue create。使用者說不用就繼續。

產出物：一句可驗收的完成條件，格式為「當 ___ 時，___ 應該 ___」。

⚠️ 如果寫不出這句話，代表需求還沒被想清楚 —— 這時候回頭問使用者， 不要靠猜測開始寫程式。

Step 2 — 同步基底並切分支

git status --porcelain          # 必須乾淨；有未提交變更先問使用者怎麼處理
git rev-parse --verify origin/develop   # 判斷基底分支

基底分支：有 develop 就用 develop，否則退回 default branch，並告知使用者 「此 repo 無 develop，改以 為基底」。

git pull origin <base>
git checkout -b <type>/<scope>-<action>

命名規範（見全域 CLAUDE.md）：

<scope>-<action> 用 kebab-case，總長 ≤4 個詞：feat/admin-analyze、fix/connectors-error。 只用這兩個前綴，讓 git log 能一眼分出「修補 vs 擴張」。

Step 3 — 決定改動範圍

先讀再寫。用 Grep/Glob 找出：

• 這個需求該落在哪個既有模組
• 有沒有已存在、可直接沿用的函式或元件（優先重用，不要新造）
• 專案的既有慣例：命名、錯誤處理、測試放哪、用什麼框架

分流：

• 單檔、邏輯直觀 → 直接做
• 跨多檔、或有多種合理設計 → 先列 3–6 步的計畫給使用者確認再動手

Step 4 — 實作

• 貼合既有風格：註解密度、命名、慣用寫法都比照周圍程式碼，不引入個人偏好

• 一次只解一個問題：不順手改風格、不順手重構無關的東西（那是 /simplify 的事）

• 測試：不強制 TDD。但改動涉及條件分支、邊界值、或修 bug 時要補測試。

  ⚠️ 期望值由規格決定，不是由程式輸出決定。 嚴禁先跑一次程式、再把跑出來的結果填成 assert —— 那只是在測「程式做了它做的事」， 永遠不會失敗。想不出預期值就回 Step 1 釐清規格。

• 跑既有驗證：找到專案自己的指令（package.json scripts、Makefile、pyproject.toml…） 並執行 lint + test。有紅燈就修到綠，不要留給下一棒。

Step 5 — Commit

git add <明確路徑>        # 不要 git add -A
git commit

• Conventional commit：feat(scope): ... / fix(scope): ...
• 內文寫為什麼，不是改了什麼（改了什麼 diff 自己會講）
• 有 issue 就加 Refs #123
• 沿用該 repo 既有的 commit trailer 慣例（先看 git log -3 確認）
• 只 commit，不 push

Step 6 — 交棒

回報使用者：

• 完成條件（Step 1 那句話）
• 分支名 + commit hash
• lint/test 實際結果（貼輸出，不要只說「通過」）
• 刻意沒做的事（例如：未補 E2E、某個邊界暫不處理）
• 下一步：/simplify → /code-review → 開 PR（base 一律 develop）

不做的事