review-pr

# review-pr 以 reviewer 角色審查別人的單一 PR，依 repo rules / handbook / diff context 留 inline comments，並送出 GitHub review。 ## Contract 此 skill 只處理單一 PR review。多 PR discovery 與 batch orchestration 交給 `review-inbox`；修自己的 PR review comments 就直接修（那不需要重簽成功的定義）。 Reviewer stance：prioritize bugs、behavior regressions、security、type safety、project rule violations、missing tests。不要用 personal style preference 擋 merge。 reviewer-side 屬 read-only lane，但對 `changes_requested`、`active unresolved comments`、 `awaiting_re_review`、`mergeable_ready` 的語義必須與 author-side mutable lane 一致；不得自行重寫。 本 skill 可輸出 reviewer 結論（`APPROVE` / `COMMENT` / `REQUEST_CHANGES`），但不得把 reviewer 結論寫成 author-side stage authority；「可 merge / 可 release / 已完成」仍必須沿用 shared PR / workflow state，而不是 reviewer prose。 ## 這支 skill 有沒有被叫對：`evals/evals.json` 上面那條界線（什麼走這支、什麼走 `review-inbox` / `request-pr-review`）不是只寫在散文裡， 它有一份**具名的案例集**：`evals/evals.json`，13 句真的會被打出來的話，7 句該觸發、6 句 不該。每一條帶著它為什麼在那裡（`notes`）。 **它是給人讀的，不是給腳本跑的**——這裡沒有 runner，也刻意不要有一支。它的用途是：改 frontmatter 的 `description` 之前先讀那 13 句，問「改完之後這 13 句的答案還一樣嗎」。負向 那 6 句尤其重要，因為觸發詞放寬的代價從來不出現在正向案例上。 **什麼時候要更新它**：這支 skill 被叫錯、或該叫沒叫到的那一刻——把那句原話補成第 14 條， 標好它該不該觸發。一句在真實對話裡走錯的話，比十句想像出來的案例有用。同一趟摩擦也記進 你手上那張單可以改的那部分（`SKILL-UTILITY`，見 `driving-work-to-done`），兩者不重複：那裡記 「這一趟它幫到還是擋到」，這裡記「這句話該路由到哪」。 ## Reference Loading | Situation | Load | |---|---| | Any run | `review-pr-entry-fetch-flow.md`, `pr-input-resolver.md`, `workspace-config.yaml` | | Analysis | `review-pr-analysis-flow.md`, `library-change-prot...