Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

loom-requesting-code-review

Estrelas5

Forks0

Atualizado8 de julho de 2026 às 08:51

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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

xiqin

xiqin/loom

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

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

请求代码审查

触发条件

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。

Mais deste repositório

mesmo repositório

loom-analyze-artifacts

xiqin/loom

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.

2026-07-225

loom-brainstorming

xiqin/loom

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.

2026-07-225

loom-converge

xiqin/loom

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.

2026-07-225

loom-detail-expansion

xiqin/loom

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.

2026-07-225

loom-omission-hunter

xiqin/loom

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.

2026-07-225

loom-pipeline-selector

xiqin/loom

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.

2026-07-225

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

请求代码审查

触发条件

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：双轴预审查

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。