Judge

Agent skills for agentic coding tools. Extremely opinionated. Updated (almost) daily.

Install

npx -y skills add JHostalek/dotclaude --skill judge

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when the user wants an independent expert review of work done in this conversation before accepting or extending it.

SKILL.md

3.5 KB, as published. Nobody here has run it

subject = $ARGUMENTS

No subject → review most recent substantive work in this conversation; identify from context, confirm with user before spawning. Subject references a path → read enough to know full scope before dispatching.

Why this exists: the engineer who built something is the worst judge of it — they see what they intended, not what's there. Reviewers with clean context catch approach-level errors and missed alternatives the author rationalizes away, without the cost of a human code review.

You coordinate; teammates judge. Don't run the review yourself; dispatch + synthesize.

Scope

Not /audit-necessity (should it exist). Given we're building it, did we build it the way an expert would? Approach selection, architecture fitness, idiom correctness, trade-off awareness, missed alternatives, domain-standard solutions, proportionality.

Teammates

Spawn three clean-context reviewers, read-only and analysis-only. Domain, proportionality, and alternative-path coverage is the minimum panel.

Teammate	Agent file	Lens
Domain Expert	`domain-expert.md`	Would a senior specialist in this exact domain do it this way?
Pragmatist	`pragmatist.md`	Is this the most direct path to the goal?
Alt-Path	`alt-path.md`	What fundamentally different approaches did we not consider?

Each gets: subject description, all relevant file paths / code / context, and the project's stack + conventions (detect from codebase).

Each reports everything its lens surfaces, unfiltered — the credibility pass below is yours, and it only works on a complete list. A teammate that pre-filters hands you a short list you can't distinguish from a thorough one.

Synthesis

Credibility filter

This is the filter stage; teammates do not run it. Drop any finding that fails one of:

Substantiated — cites specific code/decision/pattern, not "generally speaking".
Actionable — proposes a concrete alternative, not just criticism.
Trade-off honest — states the alternative's costs too.
Calibrated — separates "this is wrong" from "valid but here's another" from "fine, style preference". Overclaiming is this skill's #1 failure mode.

Also drop: style preferences dressed as expertise, findings where the teammate misread the constraints.

Convergence

2+ teammates independently flag the same concern → elevate it. Teammates contradict → present both with reasoning, don't pick a winner.

Verdict scale

Verdict	Meaning
EXPERT-GRADE	A domain expert would recognize this as their own work. Style nits at most.
SOLID	Sound approach. Real improvements found, no fundamental issues.
RETHINK	Functional, but an expert would take a meaningfully different approach.
RED FLAG	Fundamental approach issue. Specific alternative(s) strongly recommended.

Report

Verdict — one word + one-sentence justification
What's strong — what teammates validated (criticism-only reports read as dishonest and lose trust)
Findings — grouped by importance. Each: concern, evidence, proposed alternative, trade-off of alternative, source teammate(s)
If we could start over — single highest-leverage change, if any

Stop after the report. Do not implement changes unless asked.