| name | pr-pickup |
| description | Slack collaboration layer: extracts PR URLs from Slack messages and dispatches to engineering revision mode. Does NOT modify code — all code changes, GitHub review replies, and lesson extraction are engineering's responsibility. Trigger: "pr-pickup", "pickup", Slack URL + PR intent ("pickup <slack_url>", "處理 <slack_url>", "同仁貼的 <slack_url>", "接這個 PR <slack_url>"). NOT for: reviewing others' PRs (use review-pr), first-cut implementation (use engineering directly), fixing your own PR without Slack context (use engineering with ticket key or PR URL directly).
|
| metadata | {"author":"Polaris","version":"1.0.0"} |
pr-pickup
從 Slack 訊息擷取 PR review 請求，dispatch 給 engineering revision mode 處理，完工後回 Slack thread 告知結果。
職責邊界：pr-pickup 只做協作傳遞（intake → dispatch → broadcast）。不讀 review comments、不改 code、不回覆 GitHub review、不做 lesson 萃取——這些全部由 engineering revision mode 負責。
它的 shared authority 應收斂在 intake artifact，而不是 prose 解析。Slack/PR 輸入的 canonical
解析結果由 $SKILL_DIR/scripts/resolve-pr-pickup-input.sh 定義；skill 只消費該 artifact，不能再手工
各寫一套 PR URL / thread context 判斷。
前置：讀取 workspace config
讀取 workspace config（參考 references/workspace-config-reader.md）。
本步驟需要的值：github.org、slack.channels.ai_notifications。
若 config 不存在，使用 references/shared-defaults.md 的 fallback 值。
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: Skill tool 呼叫 engineering（傳 PR URL）→ 同步等待完成
Step 3: 根據 engineering 結果組 Slack 回覆訊息
Step 4: 回 Slack thread
Step 1: 解析 Slack 輸入
先跑 shared intake resolver，而不是手工解析：
"$SKILL_DIR/scripts/resolve-pr-pickup-input.sh" \
--input "$USER_INPUT" \
--allow-empty-prs \
--format json
若 resolver 回傳 needs_slack_thread_read=true，再依 references/slack-pr-input.md 讀取
Slack thread，然後用同一支 script 完成第二階段解析：
"$SKILL_DIR/scripts/resolve-pr-pickup-input.sh" \
--input "$USER_INPUT" \
--org "$GITHUB_ORG" \
--slack-thread-file "$SLACK_THREAD_EXPORT" \
--format json
後續 Step 2-4 一律只吃這個 intake artifact，不再自行從原始訊息重解析 PR URL / thread context。
1a. 輸入型態
| 輸入 | 處理 |
|---|
Slack URL（*.slack.com/archives/*） | 讀取 Slack thread，提取 PR URL |
| 直接的 PR URL + Slack context 提示 | 使用 PR URL，從提示中取得 Slack thread 資訊 |
| 純文字無 PR URL | → Step 1c 錯誤處理 |
1b. 保留 Slack Context
記住以下資訊供 Step 4 使用：
slack_channel_id：頻道 IDslack_thread_ts：訊息 timestamp（依 references/slack-pr-input.md 的 p 參數轉換規則）slack_source: true
這三個欄位應來自 resolve-pr-pickup-input.sh 的 JSON output，不是由 skill prose 再重建。
1c. 錯誤處理：無法解析 PR URL
若 Slack 訊息中找不到 GitHub PR URL（github.com/{org}/{repo}/pull/{n} 格式）：
- 回覆 Slack thread：「無法從訊息中解析出 PR URL，請確認訊息中包含 GitHub PR 連結。」
- 告知使用者並結束流程。
若 resolver 的第一階段只得到 Slack context、尚未得到 PR URL，這不算最終失敗；必須先完成
Slack thread read，再用第二階段 resolver 嘗試取得 PR URLs。只有第二階段仍 pr_count=0
時，才算真正的 no_pr_url fail-stop。
1d. 多 PR 處理
若偵測到多個 PR URL，為每個 PR 依序執行 Step 2-4（不平行——engineering revision mode 是重量級操作，同步一個一個跑較穩定）。收集所有結果後在 Step 4 統一回覆。
多 PR 清單以 intake artifact 的 pr_urls[] 為唯一權威；不得再從 Slack raw text 自行增減。
Step 2: Dispatch engineering revision mode
使用 Skill tool 同步呼叫 engineering，傳入 PR URL：
Skill("engineering", "<PR_URL>")
engineering 進入 revision mode（依 engineering SKILL.md Step 0 mode detection），同步執行完成後回傳結果。
2a. engineering 可能的回傳結果
| 結果 | 含義 |
|---|
| 成功完成 | engineering 已回傳 shared PR state readiness；pr-pickup 只可轉述該 state，不可自行判定「已完成 / 可 merge / 可 release」 |
| 退回 breakdown | plan gap — 施工圖有漏洞，需退回上游重新規劃（D3） |
| 退回 refinement | spec issue — AC 本身有問題，需退回需求釐清（D3） |
| 硬擋（無 task.md） | PR 沒有新版 task.md，需先跑 refinement Bug source mode 或 breakdown 補 work order |
| 失敗 | 其他原因（build 失敗、環境問題等） |
Step 3: 組 Slack 回覆訊息
根據 Step 2 結果，組裝對應的 Slack 回覆訊息。
成功完成
:white_check_mark: *PR Review 已處理*
<{pr_url}|#{number} {title}>
{engineering 回傳的修正摘要}
shared PR state: `{awaiting_re_review | mergeable_ready}`
若是 `awaiting_re_review`：已修正並 push，請 reviewer re-review。
若是 `mergeable_ready`：shared PR state 已顯示進入 merge lane readiness；是否實際 merge 仍由下游 reviewer / owner 決定。
退回 breakdown / refinement（plan gap / spec issue）
:no_entry: *PR 需退回上游規劃*
<{pr_url}|#{number} {title}>
*原因*: {engineering 回傳的 classification 理由}
*退回層級*: {breakdown / refinement}
:point_right: *下一步*: 執行 `/breakdown {TICKET}` 或 `/refinement {TICKET}` 補強施工圖後重新進入 engineering。
硬擋（無 task.md）
:no_entry: *PR 無 task.md，無法進入 revision mode*
<{pr_url}|#{number} {title}>
此 PR 沒有對應的新版 task.md。
:point_right: *下一步*: Bug 執行 `/refinement {TICKET}`，Story/Task/Epic 執行 `/breakdown {TICKET}`，建立 `specs/{EPIC}/tasks/T*.md` 後再重新觸發 engineering。
失敗
:warning: *PR 處理失敗*
<{pr_url}|#{number} {title}>
*原因*: {失敗描述}
需要人工介入處理。
Step 4: 回 Slack thread
使用 slack_send_message MCP tool 回覆原始 thread：
slack_send_message({
channel_id: "<slack_channel_id>",
thread_ts: "<slack_thread_ts>",
text: "<Step 3 組裝好的訊息>"
})
重要：必須帶 thread_ts 回覆在原始訊息的 thread 中，不要發成獨立訊息。
若 Step 1d 偵測到多個 PR，將所有結果合併成一則訊息回覆。
Do / Don't
- Do: 嚴守協作層職責——只做 intake / dispatch / broadcast
- Do: 完整保留 Slack context（channel_id, thread_ts）供回覆使用
- Do: 回覆時明確標示狀態（成功/退回/硬擋/失敗）和下一步指引
- Do: 只轉述 engineering 回傳的 shared PR state，不自行發明
ready / done / release complete
- Don't: 讀 PR review comments（那是 engineering 的事）
- Don't: 修改任何 code（那是 engineering 的事）
- Don't: 回覆 GitHub review comments（那是 engineering 的事）
- Don't: 做 lesson 萃取（那是 engineering 的事）
- Don't: 跑 quality check（那是 engineering 的事）
Post-Task Reflection (required)
Non-optional. Execute before reporting task completion.
Run the checklist in post-task-reflection-checkpoint.md.
