Reviewing Codebases — Method

This is the shared procedure every review agent follows. The framework standards (<framework>-standards), general-standards, and custom-standards are the content; this skill is the method.

1. Detect the stack

Inspect manifests and config to determine which framework standard(s) apply:

Composite stacks layer — load the base and the overlay (FastAPI→Python; Next.js→React+TS; TS Node backend→Node.js+TS). A monorepo may need several stacks at once.

2. Load standards in precedence order

1. The detected framework standard(s) (base before overlay).
2. general-standards (always — cross-cutting baseline).
3. custom-standards LAST. It holds project overrides + additions and is authoritative on conflict. When a finding is driven by a custom override, say so and cite the framework rule it replaces.

On overlap between framework and general, the stricter rule wins. custom-standards wins over everything.

3. Review against the rules

Walk the changed/target code against each loaded standard's rule areas — quality, security, performance, framework idioms, error handling, testing, docs. For every finding:

• Cite the rule ID (PY-SEC-1, REACT-HOOK-1, GEN-TEST-2, …). A finding with no rule ID is an opinion, not a standard violation — mark it clearly as a suggestion.
• Give file:line and a specific, actionable fix. Never "improve this."
• Note whether the rule is MUST / SHOULD / MAY.

4. Map severity → verdict

A review is blocked if any Critical remains. Prioritize security above all.

5. Report

Use the agent's report format (Code Review / QA Validation / Architecture Review). Always:

• Lead with Critical issues, then Warnings, then Suggestions.
• Include Positive Observations — reviews aren't only fault-finding.
• Make every claim evidence-based (path, line, rule ID). Don't assume test/build results — run them (QA) or state you didn't.