code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Code review

Always start by inspecting the changes. If you're on the `main` git branch, typically the (staged) git diff. If you're on a different branch, the committed and uncommitted changes compared to the main branch.

## Method

Please dispatch two subagents to carefully review the code changes. Run them on the most capable model available: in Claude Code, pass `model: fable`; in Codex, use `gpt-6-astra`. Reviewing is where depth pays off, regardless of which model wrote the code. Tell them that they're competing with another agent. Make sure they look at both architecture and implementation. Tell them that whoever finds more issues wins honour and glory.

Also have them run one targeted check on comments: read each new or changed comment as a reader who knows only this package and the public API of what it imports. Flag any mention of callers or importing packages, and any reference to internals hidden behind an abstraction the code consumes. Such context leakage is a real defect, not a comment nitpick -- surface it even when only one reviewer finds it.

Run a second targeted check on constants: flag any new package-level constant (or variable) that is used in only one place, or only within a single function. The fix is to inline the value at its use site, until a constant is genuinely needed -- reuse across functions, or a name that adds real meaning the literal lacks. Surface this even when only one reviewer finds it.

## Surfacing issues

Signal-to-noise ratio matters more than completeness. When reporting back to the caller:

- By default, only surface issues that **both** sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.
- Drop issues that only one sub-agent raised, unless the issue is **serious** -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.
- Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.

State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.

From maragudk/fabrik, MIT.

More from maragudk/fabrik