code-review-discipline

Applies verification practices for reviewing protocol changes, subagent findings, and CI gate signals.

82|9|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/awebai/aweb --skill code-review-discipline-awebai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-discipline
Source: https://github.com/awebai/aweb/tree/main/.claude/skills/code-review-discipline
Command: npx skills add https://github.com/awebai/aweb --skill code-review-discipline-awebai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss real defects because reviewers trust subagent findings without verification, check only the diff instead of all call sites, focus on first-contact paths while ignoring continuation paths, and treat CI gate signals as evidence without confirming the gate exercises the changed code. ## Core Features & Use Cases - Subagent finding verification: Treats code-reviewer subagent output as leads, requiring grep and source-level confirmation before acting on any claim. - Call-site coverage checks: Requires grepping all call sites of new helpers and the old direct calls they replace, not just the branches visible in the diff. - Two-stage protocol review: Provides a first-contact vs continuation checklist for session, conversation, and wire-protocol changes. - CI gate sanity checks: Tests whether a green or red gate actually exercises the changed code, covering Docker builds, lockfile pinning, cached fixtures, and privileged test setup. - Use Case: When reviewing a federation change that introduces an MCP shim, use this Skill to grep every branch of mail and chat tools, verify both first-contact and continuation paths route through the shim, and confirm the Docker e2e gate tests local source rather than a pinned PyPI release. ## Quick Start Load the code-review-discipline skill at the start of my code review assignment and apply its verification checklist to the current diff.

Frequently Asked Questions about code-review-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify code review findings from an AI subagent?

Treat subagent findings as leads, not conclusions. Open the actual file at the claimed line, grep for claimed missing symbols, and read the cited code before acting. Confidence in subagent output is uncorrelated with correctness, so verify both plausible and implausible findings against source.

How to review a change that introduces a helper or shim function?

Review the helper's factoring, then grep all call sites that plausibly need it, including branches not shown in the diff. Also grep for the old direct calls the helper was meant to replace, since a diff showing one updated branch does not prove other branches were considered.

What should I check when reviewing a wire protocol change?

Check both the establish stage (first-contact, handshake) and the extend stage (continuation, reply, in-session messages). Use a two-column checklist covering signature binding, target re-resolution, auth presentation, fail-closed behavior, and shim dispatch for each path.

Why does a green CI gate not prove my code change works?

A gate only provides evidence if it exercises the changed code. Docker builds with lockfile-pinned dependencies, cached fixtures, or privileged test setup can decouple the test environment from current source, making green signals false evidence for source-level correctness.

When should I load a code review discipline checklist?

Load it when reviewing wire protocol, authentication, or dispatch changes; when acting on subagent reviewer findings; when doing a fresh-eyes pass after a near-miss; and when interpreting CI signals for changes touching Docker images, lockfiles, or cached fixtures.