metyatech/skill-pr-review-workflow

PR 審查反饋工作流程

處理審查反饋

• 處理完 PR 審查反饋後，代理必須在結束之前解決對應的審查對話線程。如果代理沒有權限，則必須明確說明。
• 在重新請求審查之前，代理必須執行相關的驗證套件，並必須在 PR 註解或描述中總結結果（指令與結果）。
• 對於由代理引起的錯誤或可重複使用的推理差距所導致反饋，代理必須評估預防再次發生的措施應歸屬於測試、檢查、技能或規則。當需要更新規則或技能時，代理必須將該更新作為同一變更集的一部分。若不需要，則代理必須簡短說明為何最早的可重複使用閘門在其他地方。

重新請求審查

• 推送修正後，代理必須僅向在當前回合中發布已處理反饋的審查者重新請求審查。
• 代理不得向未發布已處理反饋或已表示無可操作問題的審查者（包括 AI 審查者）重新請求審查。
• 若沒有適用的審查者留下，代理必須詢問接下來應由誰審查。

AI 審查機器人重新審查

當儲存庫配置了 Codex 或 Copilot 審查機器人時，代理必須僅針對發布已處理反饋的機器人觸發重新審查。

• 對於 Codex 重新審查：在 PR 上留言 @codex review。
• 對於 Copilot 重新審查：使用 GitHub API 移除並重新請求機器人審查者 copilot-pull-request-reviewer[bot]。代理不得依賴基於 UI 的審查者指派。
  • 移除： DELETE /repos/{owner}/{repo}/pulls/{pr}/requested_reviewers 並帶入主體 {"reviewers":["copilot-pull-request-reviewer[bot]"]}。
  • 新增： POST /repos/{owner}/{repo}/pulls/{pr}/requested_reviewers 並帶入主體 {"reviewers":["copilot-pull-request-reviewer[bot]"]}。

GitHub 通知管理

• 代理必須使用 DELETE /notifications/threads/{id} （HTTP 204）將通知標記為已完成（從收件匣中移除通知並移至「已完成」標籤）。
• 代理不得使用 PATCH /notifications/threads/{id}， 該方法會將通知標記為已讀，但仍留在收件匣中。
• 處理完通知後，代理必須使用相同的 DELETE API 大量刪除任何剩餘的已讀但未完成的通知。

合併後清理

• 完成 PR 後，代理必須合併它，同步目標分支，並在本地和遠端刪除 PR 分支。