pr-pickuplisted

# pr-pickup 從 Slack 訊息擷取 PR review 請求，把 PR 交出去修，完工後回 Slack thread 告知結果。 **職責邊界**：pr-pickup 只做協作傳遞（intake → 交付出去 → broadcast）。不讀 review comments、不改 code、不回覆 GitHub review。修 PR 這件事本身不歸它——那多半不用立案（改的是既有 assertion 底下的做法），直接修；若連成功的定義都要改，那是 `refinement` 的事。 它的 shared authority 應收斂在 intake artifact，而不是 prose 解析。Slack/PR 輸入的 canonical 解析結果由 `$SKILL_DIR/scripts/resolve-pr-pickup-input.sh` 定義；skill 只消費該 artifact，不能再手工 各寫一套 PR URL / thread context 判斷。 ## 前置：這條線在哪個 org `resolve-pr-pickup-input.sh` 讀 Slack thread 的時候要 `--org`，因為它要在那一串裡找出屬於 那個 org 的 PR URL。**那個值問 `request-pr-review` 帶的那支命令**，它列出這台機器上被宣告 的每一個 org： ```bash bash "$SKILL_DIR/../request-pr-review/scripts/resolve-pr-context.sh" orgs ``` 只有一個就用它，不只一個就從那串訊息裡的 PR URL 判。**這裡不寫任何設定鍵**：org 是誰宣告 的、宣告在哪，由那支命令回答，這一支不認得任何一家公司。 以前這裡寫「讀 workspace config，本步驟需要的值：`github.org`、`slack.channels.ai_notifications`」 ——兩個鍵在任何一份 `workspace-config.yaml` 裡都不存在，`$GITHUB_ORG` 整支 skill 沒有人賦值， 而 `slack.channels.ai_notifications` 從頭到尾沒有任何一行讀它。 ## Bundled Authority | Script | Role | |---|---| | `$SKILL_DIR/scripts/resolve-pr-pickup-input.sh` | canonical intake resolver：統一解析 direct PR URL、Slack URL、Slack thread context、以及 thread-derived PR URLs | ## 流程總覽 ``` Step 0: 前置 config Step 1: 解析 Slack 輸入 → PR URL + thread context Step 2: 把 PR 交出去修 → 同步等待完成 Step 3: 根據結果組 Slack 回覆訊息 Step 4: 回 Slack thread ``` --- ## Step 1: 解析 Slack 輸入 先跑 shared intake resolver，而不是手工解析： ```bash "$SKILL_DIR/scripts/resolve-pr-pickup-input.sh" \ --input "$USER_INPUT" \ -