mcpField
H
honey-review

honey-review

github.com/green-ptTesting & quality34442 installsUpdated 2w ago
Repository

About honey-review

honey-review is an agent skill for reviewing diffs and identifying code that can be removed, aimed at developers seeking a concise, line-saving delete list. It distinguishes unnecessary complexity and verbosity from important safeguards and tests.

Key features

  1. 01Flags speculative or single-use abstractions
  2. 02Finds dead code and redundant comments
  3. 03Preserves validation, security, UX, and meaningful tests
  4. 04Outputs ranked findings with estimated lines saved

Use cases

  1. 01Reviewing a diff for removable code
  2. 02Finding redundant scaffolding before merging
  3. 03Getting a prioritized deletion list for a change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/green-pt/honey-for-devs --skill honey-review

After installing, type/honey-reviewin Claude Code to confirm it loaded.

Details

From the project README

Honey Review

Read the diff (git diff or the named range). Report only what to cut and why — the reverse of Honey's two write-levers.

Find

  • Over-engineering (Lever 1) — code that needn't exist: speculative params, "might need it later" branches, single-caller abstractions, hand-rolled itertools/pathlib/datetime, a new dependency for four lines, a reimplemented existing util.
  • Over-verbosity (Lever 2) — dead code, commented-out blocks, comments narrating what the code already says, redundant scaffolding.

Never flag (the carve-out is load-bearing)

Input validation, error handling, auth, secrets handling, accessibility basics, and visual/UX polish on user-facing deliverables are not bloat. A test or assert proving non-trivial logic is not bloat. Don't suggest cutting them.

Output — delete-list, one line per finding

N. path:line — cut <what>; <one-clause why> (−N lines)
  • Numbered and ordered by lines saved, deepest first, so the user can answer "cut 1 and 3".
  • End with one total line: Total: −N lines across M findings.
  • Nothing to cut → say so in one line. Don't manufacture findings.
  • Terse but human-readable (this is for a person, not an agent — that's hive-reviewer's job).

Example:

1. src/util.py:12 — cut hand-rolled flatten; stdlib itertools.chain.from_iterable does it (−9 lines)
2. src/api.js:40 — cut unused `opts` param; no caller passes it (−3 lines)
Total: −12 lines across 2 findings.

Comments

Markdown supported