review-code

name	review-code
description	A thorough multi-agent audit of an existing codebase against the development skills, with one sub-agent per domain. Use when re-engaging a project you have not touched recently, when the skills may have changed since the code was written, when auditing a specific package or domain, or when a deliberate compliance pass is wanted. Not for checking the diff you just wrote, which the develop skill already covers. Accepts an optional target: a domain keyword such as cli, node, infra, or concurrency, or a package path such as internal/server.
user-invocable	true

Review Code

Detect the project type, work out which domains apply, hand each to a sub-agent that reads the governing skills, then combine the findings into one report.

Start here: required reading

Read the manifest for every domain in scope before that domain is reviewed: by you for a targeted review, or by the domain's sub-agent for a full one. A manifest names the skills to load, the applicability rules, and how each check is verified. Read only the manifests for domains that apply to the detected project type.

Before reviewing a domain:

• ./references/review-domain-go-core.md: Go layout, idioms, logging, config, tests
• ./references/review-domain-go-cli.md: the command tree, flags and arguments, output tiers, prompts, progress
• ./references/review-domain-go-server.md: package architecture, HTTP server, OAuth, frontend
• ./references/review-domain-go-concurrency.md: goroutine primitives and the job pipeline
• ./references/review-domain-node.md: Node layout, idioms, server, auth, config, frontend
• ./references/review-domain-infra.md: Makefiles, release workflow, containers, README, extensions

Where the Expected Pattern Comes From

A manifest lists what to check and how to verify it. It does not restate what the correct answer is. The expected pattern for every check lives in the skill that owns it, and the reviewing agent reads that skill before running the check.

This is deliberate. A check table that repeats a rule is a second copy that drifts the moment the skill is edited, and the copy in the review is the one nobody notices is stale. Improving a skill improves the review for free.

Every finding cites the skill and the section it comes from. A finding that cannot cite one is not a finding, and reporting it anyway trains the reader to ignore the report.

Workflow

Step 1: Detect the project type

Indicator	Type
go.mod with cmd/ and utils/, no internal/server/	Go CLI Only
go.mod with internal/server/static/, no utils/	Go Web Only
go.mod with internal/server/static/ and utils/	Go CLI + Web
go.mod with internal/server/ and no static/, no utils/	Go Headless API Service
go.mod with no main.go and no cobra	Go Library
manifest.json carrying manifest_version	Chrome Extension
package.json with "type":"module", plus public/ and src/, no go.mod	Node Web Only
go.mod alone	treat as Go CLI Only

Report and stop when nothing matches, since a review against the wrong taxonomy produces findings that are all false.

Step 2: Parse the target

With no target, go to Step 3a. With one, resolve it here first.

Keywords	Domain	Scope
core, foundations, layout, logging, idioms, config	Go Core	whole domain
tests, testing	Go Core and Node	the testing checks only
cli, cobra, structure, root, commands, flags, args, stdin, output, prompts, progress, tui	Go CLI	whole domain
server, backend, frontend, web, http, auth, oauth, markdown, mermaid	Go Server and Frontend	whole domain
concurrency, goroutines, pipeline, highway	Go Concurrency	whole domain
node, nodejs, esm	Node	whole domain
makefile, assets, build	Infrastructure	Makefile checks only
ci, cd, cicd, release, workflow	Infrastructure	release workflow checks only
docker, container, dockerfile	Infrastructure	container checks only
readme	Infrastructure	README checks only

A target containing / is a package path:

Path	Domains
cmd/**	Go CLI
utils/**	Go CLI
internal/server/static/**	Go Server and Frontend
internal/server/**	Go Server and Frontend
internal/auth/**	Go Server and Frontend
internal/highway/**, internal/display/**, internal/jobs/**	Go Concurrency
internal/**, anything else	Go Core and Go Server and Frontend
src/**, public/**, test/**, package.json	Node
.github/**, Makefile, Dockerfile, README.md	Infrastructure

A target that matches no keyword row and contains no / resolves to nothing, and is reported rather than guessed at:

No domain matches the target "[target]". The domains are core, cli, server, concurrency, node, and infra.

Guessing at the nearest-looking domain reviews something the user did not ask about, and every finding it produces is noise they have to read before discarding. Naming the domains costs one message and lets them say which they meant.

When the resolved domain does not apply to the detected project type, report that and stop:

The [domain] domain does not apply to this project type ([project type]).

Otherwise go to Step 3b.

Step 3a: Full review

Project type	Domains
Go CLI Only	Go Core, Go CLI, Go Concurrency (conditional), Infrastructure
Go Web Only	Go Core, Go CLI, Go Server and Frontend, Infrastructure
Go CLI + Web	Go Core, Go CLI, Go Server and Frontend, Go Concurrency (conditional), Infrastructure
Go Headless API Service	Go Core, Go Server and Frontend, Go Concurrency (conditional), Infrastructure
Go Library	Go Core
Chrome Extension	Infrastructure
Node Web Only	Node, Infrastructure

With one domain applying, handle it inline: read the manifest, load its skills, run the checks, and produce the report. Spawning a single sub-agent adds a round trip and no parallelism.

With several, launch one sub-agent per domain, all in a single message so they run concurrently.

Resolve [SKILLS_DIR] to an absolute path before building any prompt: it is the parent of this skill's own directory. Sub-agents run in the target project's working directory, so a relative path resolves against the wrong root.

You are a focused code review agent for the [DOMAIN_NAME] domain.

## Context
- Project type: [PROJECT_TYPE]
- Working directory: [CWD]
- Skills directory (absolute): [SKILLS_DIR]

## Instructions

1. Read your domain manifest:
   [SKILLS_DIR]/review-code/references/review-domain-[DOMAIN_FILE].md

2. Read, in full, every skill the manifest lists. They are at
   [SKILLS_DIR]/[SKILL_NAME]/SKILL.md
   The manifest states what to check and how to verify it; the skill states what the
   correct answer is. Running a check without having read its skill produces a
   finding you cannot cite.

3. Inspect the project in [CWD] against every check in the manifest that applies to
   [PROJECT_TYPE]. Use Read, Glob, Grep, and read-only Bash. For a conditional check,
   detect whether the pattern is present before reviewing it. Read the actual source
   files rather than inferring from names.

4. Report using the output format in the manifest.

5. Do not flag anything that is not defined in a skill you loaded. If you cannot cite
   a specific skill section, it is not a finding.

6. End your response with exactly:
   SUMMARY_LINE: categories_checked=N pass=N issues=N skipped=N total_issues=N

Go to Step 3c.

Step 3b: Targeted review

Handle it inline with no sub-agents. Read the manifest, load the skills it names, narrow to the requested subset or package scope, run the applicable checks, and produce the report.

A package path narrows file-existence checks to that package while keeping cross-cutting checks such as error handling and logging, since those are the ones a package most commonly gets wrong in isolation.

Go to Step 3c.

Step 3c: Comment audit

Run this once for the whole review rather than per domain, over the files in scope.

rg -n '^\s*(//|/\*|\*)' --glob '*.go' --glob '*.js' --glob '*.ts' <scope>

Read each hit and map it to one of the two exceptions in AGENTS.md (CLAUDE.md if you are Claude). Anything that maps to neither is a low finding citing that rule, with file:line and delete as the disposition. The comment rules are the one source outside the skills that produces a finding, so a citation to them satisfies the citation requirement everywhere it appears.

Go to Step 4.

Step 4: Report

Combine the sub-agent outputs, or use the inline findings.

## Code Review Report: [Project Name]

**Project type:** [type]
**Review scope:** [Full | Targeted: domain | Targeted: path]
**Skills checked against:** [list]

---

[domain sections]

---

### Summary

| Category | Status | Issues |
|----------|--------|--------|
| Project Layout | PASS | 0 |
| Core Principles | ISSUES | 2 |

**Total issues found:** N

Step 5: Offer to fix

Would you like me to fix these issues? I can address them one category at a time.

Work through the categories in order when the answer is yes.

Principles

Be specific enough to act on. "Missing PrintFatal in utils/printer.go" is a finding; "the utils package is incomplete" is a complaint.

Every finding carries file:line, a severity, and what to do about it. A finding without a location is a complaint, and one without a disposition leaves the reader to redo the analysis that produced it.

A finding changes behavior, breaks a build, or opens a hole. Severity is high when it breaks a build or opens a hole, medium when behavior is wrong in a case a user can reach, and low when a loaded skill's rule is broken with no behavioral consequence yet. Style preferences, naming, and hypotheticals are not findings at any severity, because a report padded with them trains the reader to skim past the two that matter.

Every expected value and every suggested fix comes from a loaded skill rather than from general practice, because a review that invents standards produces work nobody agreed to.

Detect before diving. Check whether a pattern is even used before reviewing it in depth, so a project with no goroutines gets a skip rather than a paragraph.

Skip categories that do not apply to the detected project type. A utils/ finding against a Web Only project is backwards: its absence is the rule.

Out of Scope

None of the following is defined in any skill, so none of it is ever a finding. This is the full list, and it is stated here once rather than in each manifest.

Category	Examples
Linting and formatting	no golangci-lint, no eslint, no gofmt, inconsistent formatting
Pre-commit	no hooks, no husky
Code quality CI	no lint or format steps in a workflow
Documentation beyond README	no godoc, no jsdoc, no changelog, no contributing guide
Compose files	no docker-compose for development
Database	no migrations, no schema files
Dependency tooling	no dependabot, no renovate
Security scanning	no SAST, no container scanning
Style opinions	naming conventions no skill defines, personal preference

If you are about to flag something and cannot point at a specific section of a loaded skill that defines the expected pattern, do not flag it.