What makes Code Review — Multi-Dimensional Audit notable?

1K downloads. Trust evidence available

How should Code Review — Multi-Dimensional Audit be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Code Review — Multi-Dimensional Audit

Multi-dimensional code audit using structured subagent delegation. Use when reviewing a GitHub release, PR, or codebase. Systematically inspects security, co... Skill: Code Review — Multi-Dimensional Audit Owner: yinghaojia Summary: Multi-dimensional code audit using structured subagent delegation. Use when reviewing a GitHub release, PR, or codebase. Systematically inspects security, co... Tags: audit:1.1.1, code-review:1.1.1, concurrency:1.1.1, latest:1.1.1, security:1.1.1, simplicity:1.1.1 Version history: v1.1.1 | 2026-05-15T05:18:14.034Z | user v1.1.1: Added /deep-code-

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

1.1.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.1.1release · observed May 15, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s178ctw1yw1mpyqe81gqd7y1cn84b9ms:deep-code-review

Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-yinghaojia-deep-code-review/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

70,033 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: code-review
description: >
Multi-dimensional code audit using structured subagent delegation.
Use when reviewing a GitHub release, PR, or codebase.
Systematically inspects security, concurrency/state-machine safety, UX/implementation logic, test quality, and simplicity/over-engineering.
Spawns parallel subagents for deep verification with Four-Eyes cross-validation on critical findings.
Synthesizes findings into a Confirmed/Critical-to-Low priority matrix.
Trigger phrases: review this release, audit this codebase, check this PR for issues, 代码审查, review 代码, 审查这个版本, /deep-code-review, /code-review, /review-code
---

# Code Review — Multi-Dimensional Audit Methodology

Systematically audit a codebase release through five dimensions, using parallel subagent delegation for deep verification.
Inspired by: Modern Code Review taxonomy research (Bavota & Russo 2015 "Four Eyes Are Better Than Two"), reviewdog's tool-agnostic harness pattern, Danger's pre-review gate philosophy, and community experience with AI-generated code quality issues.

## Core Principles

1. **Real code, not release notes.** Every finding must be verified against actual source files by fetching them. The only acceptable evidence is `file:line` citations. The only acceptable conclusion labels are `Confirmed / Mitigated / False Alarm`.

2. **Four Eyes on every Critical.** Any finding classified as Critical severity MUST be independently verified by a second subagent before appearing in the final report. This is the "Four Eyes" principle from Bavota & Russo (2015): multiple reviewers independently examining the same issue catch 60%+ more real bugs than a single reviewer. See [four-eyes.md](references/four-eyes.md).

3. **Simplicity is a first-class dimension.** AI-generated code often produces "massive overkill" — hundreds of lines for what should be a two-method change. Always ask: "Does the complexity of this solution match the complexity of the problem?" This dimension is inspired by community experience on Hacker News and Reddit (2025 State of AI Code Quality discussions).

## Workflow

### Phase 0: Pre-Review Gate (in main session, <2 min)

Run these quick checks before committing to a full audit. Inspired by Danger's "automated pre-review" philosophy.

1. **PR/Diff size check**: if the change exceeds 400 lines, flag it as high-risk and recommend splitting
2. **Missing artifacts**: is there a CHANGELOG entry? Updated README if API changed? Migration guide if schema changed?
3. **File-level red flags**: any committed `.env`, credentials, large binary files?
4. **Test presence**: does this change include or update tests? If zero test changes on a >100 line diff, flag.

**Output**: Gate report (pass/warn/fail) + recommended audit depth.

### Phase 1: Surface Scan (in main session)

Read these in order — enough to understand architecture and identify candidate issues:

1. **Release notes / CHANGELOG** — what the authors claim changed
2. **README** — project purpos

_meta.json

{
  "ownerId": "kn7b56gp3gfpjr0n2jxr3hkfyn82cnkm",
  "slug": "deep-code-review",
  "version": "1.1.1",
  "publishedAt": 1778822294034
}

references/audit-dimensions.md

# Audit Dimensions

Each codebase audit spans these five dimensions. For each dimension, spawn a dedicated subagent that fetches source files and verifies issues against actual code.

## 1. Security (安全审计)

**Focus**: Vulnerabilities that allow unauthorized access, data exfiltration, or resource abuse.

**Key questions to probe**:
- Are there SSRF attack vectors? Check URL fetching/redirect logic, DNS resolution, IP filtering
- Are there command injection risks? Search for `subprocess`, `shell=True`, unchecked file path concatenation
- Are there auth token leaks? Check logging, error messages, HTTP response handling
- Are there path traversal risks? Check file operations with user-controlled paths
- Are third-party dependencies validated? Check version pinning, integrity checks

**Verification method**: Trace the full attack path from user input to exploit. For each defense claim in the code, verify it actually works at the call site.

## 2. Concurrency & State Machine Safety (并发与状态机安全)

**Focus**: Race conditions, data corruption, inconsistent state in multi-thread/multi-process environments.

**Key questions to probe**:
- Are file locks (flock/fcntl) used for shared state? Is the lock scope correct (covers read-modify-write)?
- Are state transitions atomic? Check `load → modify → save` and `load → transition → save` patterns
- Are there TOCTOU (Time-of-check-time-of-use) gaps? Gap between check and action
- Are there duplicate definitions of the same named exception/class?
- Is there any lock-free concurrent write to the same file?
- For append-only logs: is `append_jsonl` properly flocked?
- For json writes: is tmp-rename used for atomicity?

**Verification method**: Construct a timeline with two concurrent operations, trace each thread's read and write points.

## 3. UX & Implementation Logic (用户体验与实现逻辑)

**Focus**: Whether the code actually implements what the docs/release-notes claim, and whether user-facing behavior is correct.

**Key questions to probe**:
- Do feature flags/modes actually enforce their claimed semantics? (e.g., "review-only" truly limits to reviews)
- Are there dead code paths that silently swallow errors?
- Are error messages actionable? Do they tell the user how to fix the problem?
- Can users recover from mistakes? Is there undo/backtrack/revisit?
- Are there implicit access control gaps? (e.g., no @-mention check in group chats)
- Do test mocks hide real bugs? Check if mocked interfaces match actual call signatures
- Are there misleading code comments that describe behavior not implemented?

**Verification method**: Trace each code branch and confirm the actual behavior against the documented claim. For each error path, read the error message and assess if a user could act on it.

## 4. Test Quality & Coverage Blind Spots (测试质量)

**Focus**: Whether tests actually catch the bugs they claim to prevent.

**Key questions to probe**:
- Do integration tests use real dependencies or mocks? If mocked, do mocks validate call s

references/four-eyes.md

# Four-Eyes Cross-Verification Protocol

## Origin

Bavota & Russo (2015), "Four Eyes Are Better Than Two: On the Impact of Code Reviews on Software Quality", found that multiple independent reviewers examining the same code catch 60%+ more real defects than a single reviewer. This protocol operationalizes that finding for AI subagent review.

## Protocol

### When to activate

Four-Eyes cross-verification is **mandatory** for:
- Any finding classified as **Critical** by a primary subagent
- Any finding where the primary subagent reports "confirmed with medium confidence" or similar hedging

### How to execute

1. **Spawn a second subagent** with the **exact same issue prompt** as the primary
2. The second subagent must have a **different dimension focus** than the primary (to avoid groupthink)
3. The second subagent sees only the issue prompt — NOT the primary's findings (to ensure independence)
4. Both reports are compared after completion

### Resolution rules

| Primary says | Second says | Final conclusion |
|---|---|---|
| Critical | Critical | **Confirmed** + `👁️ Four-Eyes Verified` badge |
| Critical | High/Medium/Low | **Confirmed** at the higher severity. Add note: "Second reviewer rated lower at [severity]." |
| Critical | Mitigated | **Mitigated** (the second found a defense the first missed). Keep both reports in appendix. |
| Critical | False Alarm | **False Alarm** (the second found the issue doesn't exist). Keep both reports in appendix. |
| Critical | Disputed (disagrees but can't reclassify) | **Disputed** — flag for human reviewer. Include both conclusions. |

### Reporting format

In the final report, Critical findings carry:

```
### 🔴 Critical: [Issue Title]
👁️ Four-Eyes Verified by [subagent-2-name]
```

Disputed findings carry:

```
### ⚠️ Disputed: [Issue Title]
🔴 Subagent 1 ([dimension]): Critical — [summary]
🟢 Subagent 2 ([dimension]): Mitigated — [defense found]
→ Human review recommended.
```

## Cost/benefit guidance

- **Small codebase (<20 files)**: Four-Eyes only on findings the auditor is uncertain about
- **Medium codebase (20-100 files)**: Four-Eyes on all Critical findings
- **Large/mission-critical codebase**: Four-Eyes on Critical + High findings

The additional cost is ~25-40% more subagent compute, but the false-positive reduction makes it worthwhile for release-blocking decisions.

references/output-format.md

# Output Format Specification

## Per-Issue Format

Every issue found must be reported with:

```
### 🔴/🟡/🟢 [Severity]: [Issue Title]

**结论**: Confirmed / Mitigated / False Alarm / Disputed
[If Critical + Four-Eyes verified: 👁️ Four-Eyes Verified by [subagent-name]]

**源码证据**: [file:line range — the specific code that proves the issue]
[Optional: quote the relevant code block]

**风险场景**: [Concrete scenario — user does X → system does Y → consequence Z]

**修复建议**: [Actionable, specific fix — not "consider improving"]
```

## Synthesis Format (after all subagent reports)

Aggregate findings into:

### 1. Summary Table by Severity

```
| # | 问题 | 来源(审计维度) | 根因(一行) | 👁️ |
|---|------|--------------|----------|-----|
```
`👁️` column: ✅ if Four-Eyes verified, blank otherwise.

### 2. Priority Matrix

```
| 优先级 | 问题 | 工作量 | 影响范围 |
|--------|------|--------|----------|
| P0 🔴 | ... | 1行代码 | 所有用户 |
| P1 🔴 | ... | ~30行 | 特定场景 |
```

### 3. Simplicity Score (NEW v1.1.0)

A 1-5 rating of how well the codebase's complexity matches its problem domain:
- **5/5** 🏆 — Elegantly minimal. Every line earns its place.
- **4/5** ✅ — Clean. Minor nitpicks.
- **3/5** ⚠️ — Acceptable. Some bloat but functional.
- **2/5** ❌ — Over-engineered. Needs refactoring.
- **1/5** 🚨 — Massively bloated. Do not merge.

### 4. Executive Summary

One paragraph that captures the overall quality assessment + top 3 action items.

## Emoji Convention

- 🔴 Critical — System violates core guarantees
- 🔴 High — Significant impact, fix before next release
- 🟡 Medium — Degrades UX or creates operational risk
- 🟢 Low — Cosmetic, theoretical, or well-mitigated
- ✅ Mitigated — Concern exists but defended elsewhere
- ❌ False Alarm — Concern does not exist
- ⚠️ Disputed — Four-Eyes reviewers disagree (needs human)
- 👁️ Four-Eyes Verified — Independently confirmed by a second subagent

Use the emoji in the severity tag, not the conclusion tag.

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.