mcpField
C
code-review-burntsushi

code-review-burntsushi

github.com/wilbeibiTesting & quality239 installsUpdated 2d ago
Repository

About code-review-burntsushi

A code-review skill based on BurntSushi’s question of whether code behaves as advertised. It guides reviewers through general review axes and Rust-specific checks, then presents findings by severity with concrete alternatives.

Key features

  1. 01Reviews ten general code axes
  2. 02Adds two Rust-specific review axes
  3. 03Orders findings by severity
  4. 04Connects findings to files and lines
  5. 05Suggests a concrete alternative per finding

Use cases

  1. 01Reviewing a patch or source file
  2. 02Checking Rust encoding and ownership assumptions
  3. 03Finding hidden costs and failure modes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/wilbeibi/wilbeibi-skills --skill code-review-burntsushi

After installing, type/code-review-burntsushiin Claude Code to confirm it loaded.

Bundled filesREFERENCE.md

Details

From the project README

code-review-burntsushi

"Is there a reasonable expectation that the code will behave as advertised?" — BurntSushi

A code review should ask: is this code honest about its invariants, failure modes, costs, and semantics? Not just: does it work?

Quick start

Paste a diff or file and say "burntsushi review" or "honest review". Walk the ten general axes in REFERENCE.md, add the two Rust-specific axes if the code is Rust, then emit findings.

Steps

  1. State the change — what is this patch doing in one sentence? If unclear, ask first.
  2. Walk all ten general axes from REFERENCE.md in order. Flag every axis with a finding.
  3. If Rust: also apply the two Rust-specific axes (encoding invariants, ownership/allocation).
  4. Emit findings first using the output contract below.

Output Contract

  • Lead with findings, ordered by severity. Use Must fix, then Consider, then Open questions; omit empty sections.
  • Prefix findings with [Axis N | file:line].
  • Each finding names the invariant, cost, or failure mode and gives one concrete alternative.
  • Add a brief Summary after findings. Do not add praise unless the user asks.

Tone rules

  • Name the invariant, failure mode, or hidden cost precisely.
  • Suggest one practical alternative per finding.
  • Do not nitpick style, naming, or formatting unless it obscures correctness or cost.
  • Do not complain about unwrap/assertions on static programmer invariants — only flag panics when the failure source is runtime/user/environment.

Reference

  • REFERENCE.md — all axes with examples, model comments, and skill rules.

Comments

Markdown supported