peer-pr-reviewlisted

# 代码改动第一性审查 目标不是替改动者证明方案正确，也不是为了显得严格而强行找问题。无论审查同事还是自己的代码，都要在有限时间内回答六件事：这块功能负责什么、实际出了什么问题、根因是什么、代码链路怎样变化、改动是否合理、还有没有必须修正或补证的地方。 默认把读者视为第一次接触该项目的新手。报告主体只保留会影响理解、提交、合并决定或后续验证方式的信息；不要用一串术语和方法名代替解释。具体 Case 走读不设机械字数上限，以读者能沿真实输入、判断、状态变化和下游结果完整听懂为准，但不要重复粘贴同一份图、表和代码。 ## 输入与边界 最低输入是一个可定位的审查对象，例如： - CodeUp PR 链接； - 当前仓库的 staged、unstaged 和 untracked 改动； - 指定 worktree 路径或本地分支； - 明确的 commit、patch 或比较范围。 需求背景通常应提供，但若当前对话、关联工作项、提交说明或代码能可靠恢复，就先自行整理；无法恢复时仍可做实现质量审查，但要明确“需求符合性未验证”。可选输入包括 OA 需求/缺陷 ID、project ID、Chat ID、环境、复现步骤、日志、改动者判断的根因和修复方案。 缺少可选输入时继续做能完成的静态审查，不把可自行检查的问题反问用户。只有审查对象无法访问、仓库或 worktree 无法定位、比较基线存在多个合理选择，或某个缺失选择会实质改变审查范围时才请求补充。 本 Skill 默认只读： - 不修改代码、配置、数据库或文档； - 不在 CodeUp 上评论、通过、关闭或合并 PR； - 不 commit、push 或部署； - 数据库只允许 SELECT；日志和配置只读取与当前假设有关的最小范围； - 不在报告中回显 Token、Cookie、凭据、完整 Prompt 或未脱敏业务数据。 ## 事实获取顺序 按成本从低到高取证，证据足够支撑结论就停止，不为低风险改动制造不成比例的调查。 ### 1. 固定审查对象 先识别审查模式并在报告顶部写明“审查对象、基线、终点和包含范围”： - **CodeUp PR**：解析仓库、源分支、目标分支、当前 patch set 和 commit。优先通过已登录页面、只读 OpenAPI 或对应 Git 远端取得不可变 diff，并读取 PR 描述、讨论和 CI。 - **当前未提交改动**：默认审查 `HEAD → 当前工作区`。分别读取 `git diff --cached`、`git diff` 和 `git ls-files --others --exclude-standard`；相关 untracked 文件必须读取，不能因普通 `git diff` 看不到就漏审。生成物、二进制或明确无关文件可以排除，但要在范围中说明。 - **worktree 或本地分支**：先用 `git worktree list`、`git status`、当前分支、HEAD 和远端信息确认实际路径。默认以用户指定目标分支为基线；未指定时只在仓库默认分支明确时使用其最新远端引用，并以 merge-base 为起点，审查 `merge-base → HEAD`，再叠加该 worktree 的 staged、unstaged 和相关 untracked 改动。基线不唯一时不要擅自选择。 - **commit 或 patch**：按用户明确给出的不可变范围审查，并记录两端 commit 或 patch 来源。 若 PR