code-reviewlisted

# Code Review（代码审查） 对 `HEAD` 与用户提供的 fixed point 之间的 diff 进行双轴 review： - **Standards（规范）**：代码是否符合本仓库文档化的编码规范？ - **Spec（规格）**：代码是否忠实实现了原始 issue / spec？ 两个轴作为**并行的 sub-agent** 运行，以免污染彼此的上下文，然后本 skill 汇总它们的发现。 issue tracker 应该已经提供给你。如果 `docs/agents/issue-tracker.md` 缺失，让用户运行 `/setup-rolex-skills`。 ## 流程 ### 1. 确定 fixed point 用户说过的任何 fixed point（commit SHA、branch 名、tag、`main`、`HEAD~5` 等）。如果他们没有指定，就问一个。 把 diff 命令一次性记下来：`git diff <fixed-point>...HEAD`（三个点，这样比较的是 merge-base）。同时通过 `git log <fixed-point>..HEAD --oneline` 记下 commit 列表。 在进一步操作之前，确认 fixed point 能解析（`git rev-parse <fixed-point>`）且 diff 非空。一个坏的 ref 或空 diff 应该在这里就失败，而不是在两个并行 sub-agent 内部。 ### 2. 定位 spec 来源 按以下顺序寻找原始的 spec： 1. commit 消息中的 issue 引用（`#123`、`Closes #45`、GitLab `!67` 等），通过 `docs/agents/issue-tracker.md` 中的工作流获取。 2. 用户作为参数传入的路径。 3. `docs/`、`specs/` 或 `.scratch/` 下与 branch 名或功能名匹配的 spec 文件。 4. 如果什么都没找到，问用户 spec 在��里。如果他们说没有，**Spec** sub-agent 将跳过并报告"无可用 spec"。 ### 3. 定位 standards 来源 仓库中任何记录了代码应该如何编写的文件，例如 `CODING_STANDARDS.md` 或 `CONTRIBUTING.md`。 在仓库文档化内容之上，Standards 轴始终携带下面的 **smell baseline**：一组固定的 Fowler code smells（《Refactoring》第 3 章），即使在仓库没有文档化任何内容时也适用。两条规则约束它： - **仓库优先。** 文档化的仓库规范始终优先；当它认可 baseline 会标记的内容时，压制该 smell。 - **始终是 judgement call。** 每个 smell 是一个带标签的启发式规则（"可能的 Feature Envy"），永远不是硬性 violation。就像这里的任何规范一样，跳过工具已强制执行的内容。 每个 smell 按*它是什么* → *如何修复*来读；把它与 diff 对照： - **Mysterious Name（神秘命名）**：名称无法揭示其功能或内容的函数、变量或类型。→ 重命名它；如果找不到一个诚实的名称，说明设计本身不清晰。 - **Duplicated Code（重复代码）**：相同的逻辑形状出现在变更中不止一个