deepreview

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Deepreview

Deepreview 执行严格、基于证据的 code review。它有三种 mode：

- Current Changes Mode：review 当前 workspace 和 branch 相对 `main` 或指定 base ref 的 changes。
- PR Review Mode：review 指定 Pull Request 相对其 base branch 的完整 diff。
- All Repository Mode：review 仓库中的全部代码。

当用户要求 strict review、deep review、current unmerged changes review、PR review 或 full repository review 时，使用这个 skill。

## Invocation Handling

直接映射这些短指令：

```text
$deepreview
$deepreview 当前改动
$deepreview current changes
$deepreview --base main
$deepreview --base <ref>
```

使用 Current Changes Mode。裸 `$deepreview` 等价于 `$deepreview --base main`。如果提供了 `--base <ref>`，
就 review 当前 workspace 和 branch 相对该 base ref 的 changes，而不是默认 `main`。

```text
$deepreview PR 123
$deepreview pr 123
$deepreview --pr 123
```

对 PR number `123` 使用 PR Review Mode。

```text
$deepreview --all
$deepreview all
$deepreview full
$deepreview repo
$deepreview 全部代码
$deepreview 整个仓库
```

使用 All Repository Mode。

如果同时提供 `--all` 和 `--pr <number>`，必须询问用户是要 review 整个仓库还是指定 PR，不要自行选择。
如果同时提供 `--all` 和 `--base <ref>`，使用 All Repository Mode，并把 `--base` 仅作为可选参照基线记录到 scope。
如果同时提供 `--pr <number>` 和 `--base <ref>`，使用 PR Review Mode，并把 `--base` 仅作为需要核对 PR base
branch 的显式期望。如果用户要求 PR review 但没有给 PR number，先询问 PR number。若请求无法判断是 current
changes、PR mode 还是 All Repository Mode，只问一个简短澄清问题。

## Output Contract

始终把完整 review 结果写入 `docs/reviews/` 下的 markdown 文件。目录不存在时创建。

写 review artifact 前，必须从本机系统时钟生成 timestamp。不要推断、手写或编造 timestamp。不要使用 `001` 这类计数器。

运行或执行等价操作：

```bash
mkdir -p docs/reviews
ts="$(date +%Y%m%d-%H%M%S)"
```

Current Changes Mode 使用生成的 timestamp：

```text
docs/reviews/code-review-${ts}.md
```

PR Review Mode 使用生成的 timestamp：

```text
docs/reviews/pr-<pr_number>-review-${ts}.md
```

All Repository Mode 使用生成的 timestamp：

```text
docs/reviews/repo-review-${ts}.md
```

写入前，确认路径匹配以下格式之一：

```text
docs/reviews/code-review-[0-9]{8}-[0-9]{6}.md
docs/reviews/pr-<pr_number>-review-[0-9]{8}-[0-9]{6}.md
docs/reviews/repo-review-[0-9]{8}-[0-9]{6}.md
```

最终回复用户时，只简要说明 review conclusion 和 output file path。

## Review Method

Current Changes Mode：

1. 先理解 change intent：阅读相关 notes、diff、commit scope、关键实现和 tests，判断改动声称要解决什么问题。
2. 再对齐 contracts 和 sources of truth：检查 `AGENTS.md` / `CLAUDE.md`、相关 README 或 design docs、
   public interfaces、schemas、state machines、configuration、storage 或 external protocols。
3. 继续追踪 implementation paths：跟随关键 call chains、data flow、error paths 和 risk points，例如
   concurrency、idempotency、retry、cancellation、recovery。不要只 review 表层 diff。
4. 以真实入口为起点检查完整主链路。必须沿真实代码路径逐行走读，禁止猜测；root cause 必须来自同一条逻辑或数据路径上的直接证据。
5. 对关键 public functions，以及分支复杂、状态更新复杂或 I/O 边界明显的 private helpers，按这个顺序展开：

   ```text
   入参 -> 条件判断 -> 下游调用 -> 返回值 / raise -> 副作用
   ```

6. 检查所有关键 `if` / `elif` / `match` / dispatch / router 是否由真正决定该分支的事实驱动，而不是由间接信号、
   historical flag、cached marker 或碰巧相关字段驱动。
7. 对关键参数、配置、override 和 request options 展开生效链：来源 -> 覆盖关系 -> 最终消费点 -> 非法值处理。
   如果值只进入中间对象但最终未被执行层读取，或在链路中被重新默认化、覆盖、丢失、静默忽略，即报告。
8. 对返回值、持久化状态、外部可见状态、event/log/trace 做一致性检查。任何“返回成功但状态半提交”“外部显示完成但系统仍可恢复或运行中”
   或“错误被默认成功值掩盖”的情况，都必须沿同一执行事实追踪。
9. 执行 adversarial failure pass 和 semantic ownership drift pass：默认怀疑，寻找最强的、基于证据的理由说明该
   change 还不该 ship；特别检查是否由无所有权的下游通过 fallback、特例、重复计算、loose parsing、兼容 shim
   或测试固化来补齐上游 contract。如果只覆盖 happy path，把它视为真实弱点。
10. 最后 review tests and risk：判断 tests 是否覆盖真实行为、failure paths、boundary conditions 和 regression
   surfaces，识别重要剩余未覆盖风险。

From liuxie066/liuxie-skills, MIT.

More from liuxie066/liuxie-skills