@hope_phenom/dsh-plugin-code-quality

Usage

/simplify

/simplify                       # clean up everything changed since the upstream branch
/simplify src/parser.ts         # restrict the review to one path
/simplify 421                   # review a pull request instead of the local diff

Scope resolution, in order: a target you named, then git diff '@{upstream}...HEAD', then main...HEAD (falling back to origin/main, master), then HEAD~1. Working-tree edits and untracked files are folded in, because the command is most useful before you commit. If nothing changed, it says so and stops.

Four independent reviewers look at the diff — Reuse, Simplification, Efficiency and Altitude. A finding only counts if it names the concrete replacement: the existing helper to call, the simpler form, the cheaper alternative, or the general mechanism the special case should fold into. Findings that cannot fill that slot are dropped before they reach you.

Surviving findings are deduplicated and applied directly. Anything whose fix would change intended behavior, or that needs work outside the diff, is skipped and reported as skipped rather than argued about.

/code-review

/code-review                    # balanced review at the default level
/code-review high               # more angles, higher findings cap, recall-biased verification
/code-review max --fix          # widest sweep, then apply the findings
/code-review high src/parser.ts # level plus a target

The level word is read out of your own message — there is no argument parser, because the command is delivered as instructions.

Level	Correctness angles	Cleanup angles	Candidates per finder	Report cap	Verification bias
low	3	0	4	5	drop anything not CONFIRMED
medium (default)	5	2	6	8	balanced
high	6	4	8	12	keep PLAUSIBLE
max	6	4 + sweep	8	20	keep PLAUSIBLE

Six correctness angles are defined, and the level decides how many run — three at low, five at medium, all six at high and max:

id	angle	the question it asks
C1	line-by-line hunk scan	What input, state, timing or platform makes each changed line produce the wrong result — including unchanged lines of a touched function.
C2	removed-behavior audit	What invariant did each deleted or replaced line enforce, and where does the new code re-establish it?
C3	cross-file contract tracing	Does the change break a caller through a new precondition, return shape, throwing path or ordering requirement?
C4	language and framework pitfalls	Which classic trap of the languages actually present in this diff is being stepped in?
C5	async, concurrency and resource lifetime	Races, missing await, abandoned work, error paths that skip cleanup, listeners that outlive their owner.
C6	error paths and boundaries	Empty collections, zero and negative values, null, multi-byte text, overflow, timeouts, partial writes, oversized payloads.

Every candidate then goes to a separate verifier that is told to try to refute it and must answer CONFIRMED, PLAUSIBLE or REFUTED. At high and max, a final sweep reviewer sees the verified list and looks only for gaps. When the report cap forces a cut, correctness findings outrank cleanup, altitude and conventions findings.

Output is one line per finding:

src/parser.ts:118 — the retry loop resets `attempts` inside the loop; a persistent 503 retries forever

If nothing survives verification it says so in one line instead of padding the report. --fix applies the surviving findings after reporting them; without it the command never edits a file.

---