From 0b728ca2705483696d74ddbbf35ce3274a3eb010 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Thu, 17 Sep 2026 08:23:22 +0000 Subject: [PATCH] =?UTF-8?q?feat(sdlc-feat):=20=E5=8A=A0=E5=85=A5=E7=AC=AC?= =?UTF-8?q?=E4=B8=89=E6=AE=B5=E3=80=8C=E6=8F=90=E4=BA=A4=E8=88=87=E9=96=8B?= =?UTF-8?q?=E7=AB=8B=20PR=E3=80=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PR 描述的八個段落與順序寫在正本裡，由 pr-create 擋；正本負責的是腳本擋不住的事： 測試結果要貼實際輸出而不是改寫成一句話、被擋下來時補真的內容而不是為了通過而拼湊、 以及跨兩個功能時用 --files 分兩次跑。 先開 PR 再停錶的理由也寫進去了：工時要記在真的有做事的那段時間上。 --- prompts/sdlc-feat.md | 73 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/prompts/sdlc-feat.md b/prompts/sdlc-feat.md index d01d4fe..350fa42 100644 --- a/prompts/sdlc-feat.md +++ b/prompts/sdlc-feat.md @@ -10,6 +10,8 @@ description: 僅由 /sdlc-feat 指令叫用。領取一顆工作包、起錶、 第二段**逐項實作**：一項一項把待辦做完並即時勾選，讓議題頁的進度條隨時反映真實狀態。 +第三段**提交與開立 PR**：把變更整理成讀得懂的歷史，開出 PR，停錶。 + 這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。 ## 輸入 @@ -183,10 +185,81 @@ reviewer 得從一堆「已完成第 N 項」裡找真正的討論。 - 語言與註解格式用的是哪一份對照 - **哪些資料範例是推理來的**（MCP 取不到的那些），讓 reviewer 知道哪幾個格式還沒人對過 +## 第三段：提交與開立 PR + +### 12. 分批提交 + +全部待辦都勾完之後才進這一段。變更依類型分批： + +``` +node scripts/commit-split.js --path <目標專案路徑> --type feat \ + --subject '<繁中描述>' [--scope <功能名>] --dry-run +``` + +`--type` 是**這次程式碼變更**的類型（`feat`／`fix`／`refactor`…）；測試、文件與設定檔 +由腳本自己認出來，各自成批，不必也不能指定。 + +`--scope` 只在某一批有多個檔案時才需要：單檔那批的 scope 就是檔名。試跑會印出將建立的 +每一顆 commit 與它各自的檔案，確認無誤後拿掉旗標再跑一次。 + +**描述用繁體中文。** 日後回顧時看得懂的是中文；夾雜英文的專有名詞（函式名、旗標名） +保留原文即可。 + +一次變更橫跨兩個不相干的功能時，用 `--files` **分兩次跑**： + +``` +node scripts/commit-split.js ... --files scripts/claim.js,test/claim.test.js +``` + +一顆 commit 的描述只說得清楚一件事，硬湊在一起就失去了分批的意義。 + +### 13. 寫 PR 描述 + +固定八個段落，順序不能換——reviewer 每次都在同一個位置找到要找的資訊： + +1. **摘要** — 這個 PR 做完之後，什麼事變得可能。 +2. **需求議題** — `#<編號>`。 +3. **工作包議題** — `#<編號>`。 +4. **變更內容** — 改了什麼。commit 一覽加上新增／修改的檔案。 +5. **設計重點** — 為什麼這樣做。取捨與理由，不是實作步驟的複述。 +6. **解決的問題** — 這次修掉了什麼。有具體觸發條件的就寫出來。 +7. **影響的功能** — 誰會被影響、既有行為有沒有改變。 +8. **測試結果** — 見下。 + +**「測試結果」放實際跑過的輸出**，原樣貼上，不要改寫成「已測試通過」——那句話看不出 +跑過什麼，reviewer 沒辦法據以判斷。沒有自動化測試時，寫出 reviewer 自己能重現的手動 +驗證步驟（跑什麼指令、看到什麼算對）。 + +`pr-create` 會擋下缺段落、順序不對、以及測試結果只有空話的描述。被擋下來時**補真的內容**， +不要為了通過而拼湊。 + +### 14. 開 PR 並停錶 + +``` +node scripts/pr-create.js --repo --head <分支名> \ + --body-file <描述檔> --index <工作包編號> --dry-run +``` + +標題由腳本設為分支名，不必也不能另外指定。`--index` 是工作包議題編號，PR 開出去之後 +它會停掉那顆議題上的碼錶。 + +順序是**先開 PR 再停錶**，而且 PR 沒開成就不停錶——工時要記在真的有做事的那段時間上。 +錶本來就沒在跑不算失敗（`碼錶已停` 會是 `false` 並附一句說明），PR 仍然開出去了。 + +### 15. 回報 + +- PR 的網址與編號、標題（等同分支名） +- 建立了哪幾顆 commit +- 碼錶是否已停 +- 議題上還有沒有沒勾完的待辦（理論上應該沒有；有的話要說出來） + ## 邊界 - 第一段**不改任何一行程式碼**、不勾待辦、不提交、不開 PR——那些是後面幾段的事。 - 第二段只實作與勾選。**不提交、不開 PR、不停錶**——那是第三段的事。 +- 第三段不改任何一行程式碼。到這裡實作已經結束，要改就回第二段改完再來。 +- 不把「已測試通過」這種空話寫進 PR 描述，也不為了通過檢查而拼湊內容。 +- 不代替使用者決定 commit 的類型與描述；`--type` 與 `--subject` 都要是這次真的做了什麼。 - 不把實作規範或註解格式寫進目標專案的任何檔案。 - 不改與待辦無關的程式碼；順手想修的東西記下來說出來，不要摸進這次的變更裡。 - 不為了勾選在議題上留留言。