菜单
讀取 GitHub PR 的 review inline comments，自行判斷每則意見是否需要修復——技術正確且合理者修復後 commit、push 並回覆附 commit SHA；不需修復者直接以中文回覆技術理由。觸發時機：使用者說「回覆 PR comment」、「針對 review 回覆修正」、「gen-pr-reply PR {number}」，或要針對 code review 的每個 inline comment 回覆修正 commit。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
完整開發流程編排器。使用者說「幫我做 X 功能」時觸發，自動依序驅動所有 agent 直到 PR 建立，只在關鍵決策點暫停確認。 也可用既有 GitHub issue id 直接進入 STAGE 1（跳過 STAGE 0a/0b 規劃），例如「開發 issue #42」「處理 #54」。 PR 實際合併後，可另外觸發 STAGE 6 清理該 PR 對應的 worktree（branch 一律保留不刪除）。 小修正可走 quick 模式（單暫停點、不建 worktree），例如「快速修正 <描述>」「/gen-dev-workflow quick #54」。 觸發條件：dev workflow, 開始開發, 新功能開發, 幫我做 X 功能, 繼續, 繼續上次, 繼續開發, /gen-dev-workflow, 開發 issue #<id>, 處理 #<id>, 快速修正, quick fix, PR #<id> 合併了 清理 worktree
分析 unstaged/staged 的 git 變更，依功能相關性將檔案分組，並建立多個語意化的單元 commit。當使用者說 "commit"、"gen-commit"、"依功能 commit"、"幫我 commit"、"進行功能單元 commit"，或任何要求智慧分組並 commit 目前變更的變體時使用。也適用於使用者想把變更檔案以有意義、結構良好、依功能領域組織的訊息 commit 時。
當使用者要為已合入 main 的變更發布新版本——更新版號（pubspec.yaml / README.md）、把使用者可見的新功能同步進 README、補上 CHANGELOG、並打 git tag 推上去時使用。觸發語如「更新版本資訊」、「bump 版號」、「調整版號為 vX.Y.Z 下 tag push」、「release vX.Y.Z」、「gen-update-publish-info vX.Y.Z」。
當使用者提供 GitHub issue id 連同已解析的 issue brief，並希望 Codex 從安全的 base 建立新的 git branch 與 worktree、沿用既有命名規則、且不依賴當前 branch 名稱即完成最小開發設定時，使用此 skill。
用於安全地關閉、移除、清理 git worktree 的收尾流程。檢查 worktree 狀態，乾淨且無殘留變更時直接移除、 不需再詢問是否刪除；不觸碰任何 issue 或 ticket 的 State；只移除 worktree，對應 branch 一律保留不刪除。 觸發條件：關閉 worktree, 移除 worktree, 清理 worktree, worktree 收尾, close worktree, remove worktree
分析指定 branch 到 main 的差異，並依照 pr-comment.md 格式產出 PR comment 寫入 pr-desc.md。 觸發條件：gen pr-comment <branch-name>
基于 SOC 职业分类
| name | gen-pr-reply |
| description | 讀取 GitHub PR 的 review inline comments，自行判斷每則意見是否需要修復——技術正確且合理者修復後 commit、push 並回覆附 commit SHA；不需修復者直接以中文回覆技術理由。觸發時機：使用者說「回覆 PR comment」、「針對 review 回覆修正」、「gen-pr-reply PR {number}」，或要針對 code review 的每個 inline comment 回覆修正 commit。 |
讀取 PR inline comments → 自主技術判斷 → 該修就修、commit、push、回覆 SHA → 不該修就 pushback 並回覆理由。
如同 receiving-code-review：外部 review 是待評估的建議，不是必須服從的命令。
同時執行：
# repo 名稱（不可假設）
gh repo view --json nameWithOwner
# PR inline comments（含 comment id、path、diff_hunk、body）
gh api repos/{owner}/{repo}/pulls/{pr}/comments
# 近期 commits（識別已修正項目）
git log --oneline -20
整理所有 inline comments，每則包含：
comment_id、path、body、diff_hunk對每一則 comment，自行執行以下判斷流程：
FOR each comment:
1. READ: 完整理解 review 意見
2. VERIFY: 讀取被評論的檔案，查看目前程式碼狀態
3. EVALUATE:
- 技術上正確嗎？（對 THIS codebase）
- 會破壞現有功能嗎？
- 當初這樣寫的理由是什麼？
- 是否違反 YAGNI？（建議加的東西根本沒用到）
- 是否與專案架構決策衝突？
4. DECIDE: 修 or 不修
| 判斷 | 條件 | 行動 |
|---|---|---|
| 🔧 需要修復 | 意見技術正確、確實改善程式碼品質 | 修 code → commit → push → 回覆附 SHA |
| ✅ 已修正 | git log 中已有對應修正 commit | 直接回覆指向該 commit |
| ⛔ 不需修復 | 意見技術錯誤、缺乏上下文、違反 YAGNI、或與架構決策衝突 | 回覆技術理由 pushback |
| 🔄 設計如此 | 現行實作是有意的設計決策 | 回覆說明設計理由 |
git add <修改的檔案>
git commit -m "<type>(<scope>): <修復摘要>"
git push
合併修復：多則 comment 指向相同問題時，合併為一次修復、一個 commit。 在所有相關 comment thread 各回覆一則，指向同一個 SHA。
直接回覆 comment thread，說明技術理由：
必須 reply 到 comment thread，不可發頂層 PR comment：
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies \
-X POST \
-f body="{中文內容}"
回覆格式：
已修正，對應 commit \{sha7}`。{一句話說明修正內容}`{說明設計決策與技術理由}{指出為何不適用，引用程式碼或事實}所有 comments 處理完畢後，向使用者展示：
處理結果：
🔧 已修復並回覆：N 則
✅ 已修正（既有 commit）：M 則
⛔ Pushback（不需修復）：K 則
🔄 設計如此：J 則
若有任何新 commit，顯示 git log --oneline -N。