pr-pickup — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pr-pickup (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
從 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(參考 references/workspace-config-reader.md)。 本步驟需要的值:github.org、slack.channels.ai_notifications。 若 config 不存在,使用 references/shared-defaults.md 的 fallback 值。
| 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先跑 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。
| 輸入 | 處理 |
|---|---|
Slack URL(*.slack.com/archives/*) | 讀取 Slack thread,提取 PR URL |
| 直接的 PR URL + Slack context 提示 | 使用 PR URL,從提示中取得 Slack thread 資訊 |
| 純文字無 PR URL | → Step 1c 錯誤處理 |
記住以下資訊供 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 再重建。
若 Slack 訊息中找不到 GitHub PR URL(github.com/{org}/{repo}/pull/{n} 格式):
若 resolver 的第一階段只得到 Slack context、尚未得到 PR URL,這不算最終失敗;必須先完成 Slack thread read,再用第二階段 resolver 嘗試取得 PR URLs。只有第二階段仍 pr_count=0 時,才算真正的 no_pr_url fail-stop。
若偵測到多個 PR URL,為每個 PR 依序執行 Step 2-4(不平行——engineering revision mode 是重量級操作,同步一個一個跑較穩定)。收集所有結果後在 Step 4 統一回覆。 多 PR 清單以 intake artifact 的 pr_urls[] 為唯一權威;不得再從 Slack raw text 自行增減。
使用 Skill tool 同步呼叫 engineering,傳入 PR URL:
Skill("engineering", "<PR_URL>")engineering 進入 revision mode(依 engineering SKILL.md Step 0 mode detection),同步執行完成後回傳結果。
| 結果 | 含義 |
|---|---|
| 成功完成 | engineering 已回傳 shared PR state readiness;pr-pickup 只可轉述該 state,不可自行判定「已完成 / 可 merge / 可 release」 |
| 退回 breakdown | plan gap — 施工圖有漏洞,需退回上游重新規劃(D3) |
| 退回 refinement | spec issue — AC 本身有問題,需退回需求釐清(D3) |
| 硬擋(無 task.md) | PR 沒有新版 task.md,需先跑 bug-triage 或 breakdown 補 work order |
| 失敗 | 其他原因(build 失敗、環境問題等) |
根據 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 決定。:no_entry: *PR 需退回上游規劃*
<{pr_url}|#{number} {title}>
*原因*: {engineering 回傳的 classification 理由}
*退回層級*: {breakdown / refinement}
:point_right: *下一步*: 執行 `/breakdown {TICKET}` 或 `/refinement {TICKET}` 補強施工圖後重新進入 engineering。:no_entry: *PR 無 task.md,無法進入 revision mode*
<{pr_url}|#{number} {title}>
此 PR 沒有對應的新版 task.md。
:point_right: *下一步*: Bug 執行 `/bug-triage {TICKET}`,Story/Task/Epic 執行 `/breakdown {TICKET}`,建立 `specs/{EPIC}/tasks/T*.md` 後再重新觸發 engineering。:warning: *PR 處理失敗*
<{pr_url}|#{number} {title}>
*原因*: {失敗描述}
需要人工介入處理。使用 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,將所有結果合併成一則訊息回覆。
ready / done / release completeNon-optional. Execute before reporting task completion.
Run the checklist in post-task-reflection-checkpoint.md.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.