gh-issues

• 您有一批範圍明確的 bug issue 待處理，希望在人工審查前先進行自動化修復嘗試。
• 您執行排程的 CI/cron 流水線，希望 issue 能自動分類並建立 PR，無需人工介入（--cron 模式）。
• 您採用基於 fork 的貢獻模式，需要將分支推送至您的 fork，並建立以上游儲存庫為目標的 PR（--fork）。
• 您希望自動處理 PR 審查意見 — 使用 --reviews-only 讓 gh-issues 掃描開啟中的 fix/issue-* PR，並推送針對變更請求的修復。

• 問題描述模糊、涉及架構設計或範圍過大 — gh-issues 的子代理程式會自我評估信心分數，並跳過評分低於 7/10 的問題，但高度複雜的問題應由人工處理。
• 您需要保證正確性 — 子代理程式在可用時會執行測試，但自動產生的修正在合併至正式環境前應經過人工審查。
• 您沒有 GitHub 權杖（GH_TOKEN） — 若缺少此權杖，gh-issues 將無法向任何 GitHub API 進行驗證。

最多 8 個子代理同時並行運作，每個子代理負責單一問題的完整處理流程：建立分支、程式碼分析、修復實作、測試執行、提交、推送，以及開啟 PR。每個代理擁有 60 分鐘的時間預算，並內建信心度檢查機制——若無法以 ≥7/10 的信心度處理某個問題，將自動略過。

在 PR 開啟後，第六階段會擷取審查意見、行內評論、一般 PR 留言，甚至是嵌入式機器人審查（例如 Greptile）。可執行的評論會觸發額外的子代理程式，這些子代理程式會簽出分支、套用所請求的變更、推送更新，並以提交 SHA 回覆每則評論。

傳入 --fork user/repo 將所有分支推送至你的 fork，並從該 fork 向上游來源儲存庫發起 PR——完全符合標準開源貢獻工作流程，且無需擁有上游的寫入權限。

--cron 啟用「發送後忘記」的排程機制：協調器挑選一個符合條件的議題，啟動子代理程式，並立即退出——適合每隔幾分鐘從 cron 工作呼叫一次。--watch 則讓協調器持續運行，依可設定的間隔輪詢新議題與審查評論。

在啟動子代理之前，此技能會檢查是否存在已開啟的 PR、推送倉庫上進行中的分支，以及具有 2 小時到期時效的本地鎖定聲明檔案。這可防止重複的子代理在重疊的排程執行或監控週期中針對同一議題產生競爭。

傳入 --notify-channel 並附上 Telegram 頻道 ID，即可收到包含 PR 連結與各議題結果的最終摘要訊息。系統只會傳送最終結果，不會傳送中間狀態更新。

從排程工作中執行 /gh-issues owner/repo --label bug --limit 10 --cron。每次呼叫會挑選下一個尚未認領的錯誤議題，產生一個子代理程式來實作修復，然後結束。隨著時間推移，待辦積壓項目會在每次執行之間無需人工介入的情況下逐步處理完畢。

使用 /gh-issues upstream/project --fork myfork/project --label good-first-issue，讓 gh-issues 技能從上游儲存庫擷取議題、將修復分支推送至您的 fork，並開啟以上游為目標的 PR，完全遵循標準的貢獻者工作流程。

將 /gh-issues owner/repo --reviews-only --cron 排程與您現有的 PR 流程一併執行。每次執行時，系統會掃描所有開啟中的 fix/issue-* PR，尋找尚未處理的 CHANGES_REQUESTED 審查或行內留言，選取第一個未處理的 PR，並啟動一個代理程式來套用所要求的變更並回覆。

在衝刺規劃會議期間執行 /gh-issues owner/repo --label enhancement --watch --interval 10。該技能會擷取議題，請您確認要處理哪些項目，產生代理程式，並每隔 10 分鐘輪詢一次新議題與審查回饋——持續呈現累積結果，直到您說「停止」為止。