メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | loom-requesting-code-review |
| description | 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. |
| when_to_use | Prepare a review request after verification, including change summary, tests, and reviewer focus areas. |
| argument-hint | <spec_dir or PR context> |
| user-invocable | true |
loom-receiving-code-review 处理反馈在请求审查前，确保：
loom_graph_status 查询，否则注明图查询已跳过）请求人工审查前，先对当前 diff 做本地预审查。必须先确定 fixed point，例如用户指定的 commit/branch/tag、PR base、main 或 HEAD~1；fixed point 不明确时先问用户。
检查代码是否符合项目标准和通用工程质量：
.loom/rules/constitution.md、ADR、CONTRIBUTING、CODING_STANDARDS 等项目规范。检查实现是否忠实满足来源需求：
specs/<date+feature>/spec.md、plan.md、issue/PRD 或用户原始请求定位 spec 来源。输出必须分成两个独立区块，不合并、不重排：
## Standards
- <finding 或 无发现>
## Spec
- <finding、跳过原因 或 无发现>
## 预审查摘要
- Standards findings: <数量>，worst: <最严重问题或 none>
- Spec findings: <数量/跳过>，worst: <最严重问题或 none>
若任一轴发现 blocker，先修复并重新验证，再生成审查请求。
git diff --stat
git log --oneline -10
# 代码审查请求
**功能：** <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 | 修改 | 新增方法 |
## 审查重点
- [ ] 架构合规性
- [ ] 代码质量
- [ ] 安全性检查
- [ ] 性能影响
Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.
Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.
After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.
Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.
Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.
Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.