amanjotx/Agent-Skills

/ship

提交當前工作、推送並開啟一個 Pull Request。調用此技能即表示明確允許建立/切換分支、提交、推送以及執行 gh pr create。

嚴格規則

• 遵循使用者的 Git 安全協定：絕不變更 Git 設定；絕不跳過鉤子；絕不強制推送到 main/master；僅在使用者的修訂規則完全滿足時才進行修訂。
• 絕不提交機密（.env、憑證、私鑰、令牌）。如有發現，提出警告並排除。
• 僅暫存屬於此變更的檔案。除非樹狀結構明確且無贅物，否則不使用 git add . / git add -A。
• 使用 HEREDOC 撰寫提交訊息與 PR 內容。
• 保持此工作流程專案不可知。根據儲存庫推斷驗證指令與佈局；不硬編寫應用程式或套件名稱。
• 完成後回傳 PR 網址。

約定式提交前綴

使用符合生產標準的約定式提交。選擇一個主要類型：

前綴	使用時機
feat	新的使用者可用功能
fix	錯誤修正
refactor	內部重構，無預期行為變更
perf	效能改善
chore	維護、工具、相依性、整理
docs	僅文件
test	僅測試
ci	CI 設定 / 管線
build	建置系統或打包工具變更
style	格式化 / lint 驅動的變更，無邏輯變更
revert	還原先前的提交

格式：

type(optional-scope): imperative summary

Optional body: why this change exists (1–2 sentences).

範例：feat(auth): add refresh token rotation，fix: prevent double-submit on checkout，chore: bump lint config。

工作流程

1. 檢查（並行執行）

• git status
• git diff 和 git diff --staged
• git branch -vv（目前分支 + 追蹤資訊）
• git log -8 --oneline（訊息風格）
• 預設基底分支（偏好 main，否則為 master 或儲存庫預設）
• 遠端同步狀態（git status -sb，未推送的提交）

如果沒有可提交的內容，也沒有與此工作相關的未推送提交，則停止。不要建立空的 PR。

2. 確保正確的分支

目標：將工作落地到一個基於最新基底的專用功能分支。

1. 判斷目前分支是否適用於這些變更：

   • 如果已經是一個對此工作有描述性的主題分支（feat/…、fix/…、chore/… 或明確與變更意圖相符），且不是預設分支，則為是。
   • 如果在 main/master/預設分支、不符的主題分支、過時的無關分支或分離的 HEAD，則為否。

2. 如果目前分支不適用於這些變更：

   • 如果工作區有異動，暫存並附上清楚的訊息（預設行為；除非暫存不可行，否則不要詢問）。
   • git checkout <base>
   • git pull --ff-only（或從追蹤遠端進行等效的快進更新）
   • 建立並切換到新的描述性分支，例如 feat/short-topic、fix/short-topic、chore/short-topic
   • git stash pop 回到新的分支；如有衝突則解決。

3. 如果目前分支適用於這些變更：

   • 留在該分支。
   • 在提交前，必要時從基底更新（根據儲存庫慣例，從最新基底 rebase 或 merge；優先選擇非破壞性選項；除非使用者明確要求，否則不要強制推送）。

絕不要從預設分支直接建立 PR。

3. 提交

• 偏好一個一致的提交，除非使用者要求拆分。
• 訊息使用適當的約定前綴和祈使式摘要。
• 內容（可選）：專注於為什麼，而不是檔案列表。
• 提交後，執行 git status 確認預期狀態。
• 如果鉤子失敗：修正問題並建立新的提交。除非修訂規則完全滿足，否則不要修訂。

4. 推送

git push -u origin HEAD

當沙箱/網路/gh 阻擋操作時，請求必要的權限。

5. 開啟 PR

分析所有將合併到基底的提交（不僅是最新的）。

標題： 與提交摘要精神一致 — 清晰、具體，必要時使用約定式。避免模糊標題。

內容範本（必填）：

## 摘要

- 2–5 個要點說明上線內容及其重要性

## 原因

- 問題、動機或觸發此變更的原因

## 變更內容

- 按關注領域分組的要點（行為、API/合約、資料、UI、基礎設施、測試、文件）
- 明確指出破壞性變更、遷移或身份驗證/會話行為變化

## 架構 / 流程

至少包含一個：

1. Mermaid 圖（序列圖、流程圖或狀態圖）用於主要路徑
2. ASCII 圖用於結構、分層或變更前後對比

控制流程使用 Mermaid；樹狀圖或層級圖使用 ASCII。
圖表必須與實際 diff 一致 — 不要虛構架構。

## 風險 / 回退

- 可能的失敗模式
- 安全回退 / 緩解說明

## 測試計畫

- [ ] 審查員可執行的具體步驟
- [ ] 從專案中發現的、適合儲存庫的驗證指令

使用 gh pr create 並搭配 HEREDOC 內容建立。必要時明確設定 --base。

6. 回報

保持簡短：

• 分支名稱
• 提交摘要
• PR 標題
• PR 網址
• 任何有意未提交的檔案