菜单
Process code review feedback: classify items, implement fixes, push back with reasoning when needed. Triggered after receiving review comments on a PR or branch. Use when: code review comments have arrived and need triage, fixes, or reasoned disagreement.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | loom-receiving-code-review |
| description | Process code review feedback: classify items, implement fixes, push back with reasoning when needed. Triggered after receiving review comments on a PR or branch. Use when: code review comments have arrived and need triage, fixes, or reasoned disagreement. |
| when_to_use | Triage review feedback, implement valid fixes, and respond with evidence when pushing back. |
| argument-hint | <review comments or PR context> |
| user-invocable | true |
loom-requesting-code-review 发出请求后，收到反馈时自动触发loom-finishing-a-development-branch 收尾分支技术严谨 > 社交舒适。 验证后再行动，不搞表演性同意。
审查反馈是需要技术评估的输入，不是情感表演的机会。
永远不要：
应该：
正确的反馈回复：
✅ "已修复。[简述改动]"
✅ "好发现 - [具体问题]。已修复于 [位置]。"
✅ [直接修复，通过代码展示]
❌ "你说得对！"
❌ "好主意！"
详细检查清单见
references/response-templates.md
完整 YAGNI 检查流程、push back 方式和不清楚反馈示例见
references/response-templates.md
BLOCKER（必须修复）：
SUGGESTION（建议修复）：
讨论项：
使用 references/response-templates.md 中的统一模板格式回复审查意见。
git add <modified-files>
git commit -m "fix: 根据审查反馈修复 xxx"
git push