Code Review — choose the correct engineering review path

Decision guide for routing code-related work to the correct review path: architecture boundaries, standards-backed implementation review, test coverage and regression risk, language/framework code quality, or behavior-preserving refactor planning.

Purpose

This page routes code-related work to the correct engineering review path. It is not a combined code-review procedure. Use it to choose whether the task belongs in architecture boundary review, standards-backed implementation review, test coverage and regression review, language/framework code-quality prompting, or behavior-preserving refactor planning.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
The review path is not clear yet
Use this when the task is code-related but the main review question still needs to be classified before opening a guide or prompt.
Use case
The task could fit more than one review type
Use this when architecture, implementation correctness, testing, code quality, or refactor planning could be confused.
Use case
You need to avoid a generic code-review request
Use this before running a broad review so the work starts from the correct path and does not merge unrelated scopes.

Decision guide

Choose the correct engineering review path

Choose one path by the dominant engineering question. Open the matching procedure or prompt; do not merge paths unless the task explicitly asks for a multi-pass review.

Option 1 · Procedure
Architecture and boundaries
Use this path when the main question is whether the system structure, module boundaries, dependency direction, ownership, layering, interface boundaries, or state flow is correct.
Best for: Structural diagnosis, boundary correctness, ownership, layering, coupling, interface separation, and state-leakage review.
Use when: The review question is whether the system shape or boundary is correct.
Option 2 · Procedure
Implementation against official guidance
Use this path when the main question is whether code, configuration, API usage, runtime behavior, platform behavior, or design material follows official documentation, standards, or primary vendor guidance.
Best for: Implementation correctness, API misuse, version-sensitive behavior, configuration correctness, source applicability, and source-backed remediation.
Use when: The review question is whether the implementation is correct according to authoritative guidance.
Option 3 · Procedure
Test coverage and regression risk
Use this path when the main question is whether changed behavior is covered by tests and protected against regression.
Best for: Missing test scenarios, weak assertions, setup gaps, fixture or mock drift, coverage gaps, and regression-sensitive paths.
Use when: The review question is whether the changed behavior has enough test coverage and regression protection.
Option 4 · Prompt template
Language and framework code quality
Use this path when supplied code needs a prompt-based review for readability, maintainability, naming, modularity, error handling, dependency use, testability, and alignment with language or framework guidance.
Best for: Code-quality findings, convention-based findings, language/framework alignment, maintainability issues, and missing-evidence reporting.
Use when: The primary question is implementation quality, readability, maintainability, or language/framework practice alignment.
Option 5 · Prompt template
Behavior-preserving refactor planning
Use this path when existing code needs a prompt-based refactor plan that improves structure, readability, or maintainability while preserving externally visible behavior.
Best for: Preserved behavior, staged refactor planning, behavior-change risks, test impact, and checks to run before editing code.
Use when: The goal is to plan a refactor, not to review architecture boundaries, verify implementation against official sources, or audit test coverage.