Marcussyl/cursor-skills

分批提交 (Commit in batches)

將未提交的工作拆分為多個邏輯提交。每個提交應能獨立審查，並包含該部分所需的完整文件。

安全規則 (始終遵守)

• 永遠不要更新 git 設定。
• 除非使用者明確要求，否則永遠不要強制推送、硬重置或執行其他破壞性 Git 操作。
• 除非使用者明確要求，否則永遠不要跳過鉤子 (--no-verify 等)。
• 永遠不要暫存機密資訊 (.env、憑證、金鑰)。警告並排除它們。
• 除非完全滿足修改規則，否則永遠不要使用 git commit --amend。
• 如果提交鉤子失敗，請修復問題並建立新提交；不要修改失敗的提交。
• 不要在提交訊息中新增 Co-authored-by: Cursor。

1. 檢查

盡可能並行執行：

• git status
• git diff 和 git diff --staged
• git log -5 --oneline 以了解訊息風格
• git remote -v 和分支追蹤 (git status -sb)

如果沒有需要提交的內容，則停止並告知。

2. 規劃批次

按照目的對變更進行分組，而不僅僅是按檔案類型。例如：

• 一個功能或使用者面向的行為及其測試和文件
• 一個錯誤修復及僅修復該錯誤的檔案
• 獨立存在且不與無關功能混雜的重構
• 範圍限定在某個領域的雜項或工具（依賴項、CI、設定）

規則：

• 不要在一個提交中混雜無關的功能。
• 在同一批次中包含配套檔案（例如，一個變更的 schema + entity + migration + 呼叫點）。
• 如果一個檔案涉及兩個關注點，優先歸入主要批次，或者在提交前說明取捨。
• 按順序列出批次：基礎部分優先（共用型別、設定），然後功能，最後是依賴於先前提交的僅文件變更。

向使用者顯示一個簡短計劃：批次編號、檔案或路徑、建議的常規提交主題。除非他們反對，否則繼續執行。

3. 提交每個批次

對於每個批次，按順序執行：

1. 僅暫存該批次 (git add 指定路徑；除非整個工作目錄就是一個批次，否則避免使用 git add -A)。
2. 使用 git diff --staged 重新檢查，確保沒有無關的內容混入。
3. 撰寫常規提交 (Conventional Commit) 主題 (feat、fix、chore、docs、refactor、test 等)，重點放在原因上。
4. 如果分支名稱包含問題編號，請在主題末尾附加 #<issue> (GitLab 風格)。
5. 提交。在 Windows PowerShell 上，使用 git commit -m 'subject' (或多個 -m 表示簡短主體)。在 bash 上，可以使用 HEREDOC 來撰寫訊息。
6. 重複直到工作目錄中的預期變更被清理乾淨。

4. 推送到 GitHub (或遠端倉庫)

在所有批次完成後：

• 如果存在 origin (或使用者命名的遠端) 且分支應該被發布，則當上游遺失時執行 git push -u origin HEAD，否則執行 git push。
• 永遠不要強制推送 main 或 master 分支。
• 如果推送被拒絕，報告錯誤並建議拉取/重定基底；除非使用者明確要求，否則不要強制推送。
• 如果沒有遠端倉庫，告知提交僅在本地，並詢問是否要新增遠端。

5. 報告

摘要：

• 每個提交的雜湊值和主題 (最新的在最後或使用編號列表)。
• 推送結果 (URL 或分支名稱，如果有的話)。
• 任何故意未暫存的內容 (機密資訊、僅本地檔案)。

與 commit-msg 的關係

commit-msg 從已暫存的檔案中建議一行訊息，但不執行提交。此技能則規劃、暫存、分多步驟提交，並推送。