Loom requesting code review

Skill xiqin/loom/skills/loom-requesting-code-review

Prepare a code review request with change summary, self-test results, and focus areas for reviewers. Use when: verified changes are ready for reviewer handoff or a PR needs a review request summary.From its SKILL.md

Install

npx -y skills add xiqin/loom --skill loom-requesting-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.0 KB, as published. Nobody here has run it

请求代码审查

触发条件

verification-before-completion 通过后，需要人工代码审查时
用户主动要求发起代码审查
分支开发完成、准备合并前

完成条件与下一步

审查请求已生成并发送
下一步：等待审查反馈 → 使用 loom-receiving-code-review 处理反馈

预审查清单

在请求审查前，确保：

所有变更已提交
编译通过（BUILD_CMD）
静态分析通过（VET_CMD）
所有测试通过（TEST_CMD）
代码符合项目编码红线
图后端状态已确认（可用时通过 loom_graph_status 查询，否则注明图查询已跳过）
已完成 Standards + Spec 双轴预审查，或已说明跳过某一轴的原因

执行流程

Step1：准备审查材料

确认所有变更已完成
运行验证确保代码质量（读取宪章中的 BUILD_CMD、VET_CMD、TEST_CMD 并执行）

Step2：双轴预审查

请求人工审查前，先对当前 diff 做本地预审查。必须先确定 fixed point，例如用户指定的 commit/branch/tag、PR base、main 或 HEAD~1；fixed point 不明确时先问用户。

Standards 轴

检查代码是否符合项目标准和通用工程质量：

.loom/rules/constitution.md、ADR、CONTRIBUTING、CODING_STANDARDS 等项目规范。
架构分层、模块边界、命名、错误处理、日志、配置、安全和性能。
测试质量：是否测行为、是否覆盖边界、是否避免实现耦合。
固定坏味道基线：重复、过长函数、霰弹式修改、循环依赖、全局状态、过度 mock、临时兼容层、未解释的复杂度。

Spec 轴

检查实现是否忠实满足来源需求：

从 commit message、PR 描述、specs/<date+feature>/spec.md、plan.md、issue/PRD 或用户原始请求定位 spec 来源。
对照验收标准、Requirement ID、边界条件和不做范围。
缺少 spec 来源时，明确写“Spec 轴跳过：未找到来源”，或向用户请求来源；不得凭想象补需求。

输出必须分成两个独立区块，不合并、不重排：

## Standards

- <finding 或 无发现>

## Spec

- <finding、跳过原因 或 无发现>

## 预审查摘要

- Standards findings: <数量>，worst: <最严重问题或 none>
- Spec findings: <数量/跳过>，worst: <最严重问题或 none>

若任一轴发现 blocker，先修复并重新验证，再生成审查请求。

Step3：整理变更摘要

git diff --stat
git log --oneline -10

Step4：生成审查请求

# 代码审查请求

**功能：** <feature-name>
**分支：** feature/<date>-<feature-name>

## 变更统计

<git diff --stat 输出>

## 主要变更

1. <变更说明 1>
2. <变更说明 2>

## 重点关注

1. 架构设计：xxx
2. 安全性：xxx
3. 性能：xxx

## 自测情况

- [x] 编译通过（BUILD_CMD）
- [x] 静态分析通过（VET_CMD）
- [x] 测试通过（TEST_CMD）
- [x] 代码符合编码红线
- [x] 图后端已同步，或已注明索引查询跳过

## 变更详情

| 文件          | 变更类型 | 说明            |
| ------------- | -------- | --------------- |
| path/to/file1 | 新增     | XxxService 实现 |
| path/to/file2 | 修改     | 新增方法        |

## 审查重点

- [ ] 架构合规性
- [ ] 代码质量
- [ ] 安全性检查
- [ ] 性能影响

约束

审查请求必须包含完整的变更摘要
必须标注重点关注项
必须提供自测情况
Findings 必须优先于总结，且包含文件/行号或明确的证据来源。
缺少 spec 来源时不得伪造 Spec findings。