request-pr-review

# request-pr-review — 請人來看已經開好的 PR 實作做完、PR 開出來了，缺的是最後一步：**請同事看**。這支 skill 承載那一步的全部——這批 總共有多少、分在哪些 repo、每一個現在被誰看了、要通知誰。 三步，順序固定，**中間那一步是人**： 1. **query** 名下所有 open PR，帶回每一個的 review 狀態。 2. **列出來問使用者要怎麼處理**——列的東西要足夠讓他當場決定，不用再去 GitHub 翻一遍。 3. **照他的決定通知對的人**。 ## 這支 skill 不知道的三件事 **要看哪個 org、哪個 repo 通知誰、一張單長什麼樣。** 三者都由認領那個 org 的 skill 在 自己的 `SKILL.md` 宣告，這裡掃所有 skill 找那一行： ``` <!-- {任意前綴}-PR-CONTEXT-{org}: {命令} --> ``` 鍵裡那一段就是 org 名，所以掃一次同時回答「要 query 誰」與「拿到之後問誰」。一個宣告都 沒有時說出來並停下——**不猜一個 org，不用占位字串當預設值**。 宣告的命令要認得兩個模式，第一個參數就是模式名： | 模式 | 進 | 出 | |---|---|---| | `notify --repo R` | 參數 | 這個 repo 的 PR 通知誰，格式由那一層自己定 | | `ticket` | stdin：`repo⇥number⇥title⇥branch` | `repo⇥number⇥單號⇥單的 URL` | `ticket` 走 TSV 而不是把 PR 的 JSON 丟過去：那個資料結構是這支 skill 的事，交出去等於逼 每一家公司的知識層都得認得它。**這裡不認得任何一家公司的單號長什麼樣**，也不該認得。 所以這裡沒有前置設定要人先準備，也不需要任何環境變數。author 沒指定時自己偵測： ```bash MY_USER="$(gh api user --jq '.login')" ``` approval threshold 這類判定門檻仍讀 workspace config 的 shared defaults。 ## Bundled Scripts 路徑相對於本 skill 目錄。 | Script | 用途 | 輸出 | |--------|------|------| | `scripts/resolve-pr-context.sh` | `orgs` 列出被宣告的 org；`notify` / `ticket` 轉交給認領那個 org 的命令 | org 清單／那一層的答案 | | `scripts/fetch-user-open-prs.sh` | 名下所有 open PR，含 org/base/head | PR JSON array | | `scripts/check-pr-approval-status.sh` | approval 數、stale、被指名還沒看的 reviewer | 加上 approval 欄位 | | `scripts/fetch-pr-review-comments.sh` | 還沒被回覆的 actionable comments | 加上 `unaddressed_comments` | | `scripts/check-pr-ci-status.sh` | CI 狀態 | 加上 `ci` | | `scripts/at...