Code Review — choose the correct review path

Routing page for code review workflows. Choose architecture & boundaries or implementation vs official guidance.

Code Review: Architecture & Boundaries

Choose this when the main problem is structure, boundaries, ownership, or state leakage.

Jump to Option 1 →

Code Review: Implementation vs Official Guidance

Choose this when the main problem is whether code or configuration is correct according to official guidance.

Jump to Option 2 →

System structure

Choose Architecture & Boundaries

Use this when the main question is: “Is the system structure correct?”

This path is for structural diagnosis, ownership, and boundary correctness.

Implementation correctness

Choose Implementation vs Official Guidance

Use this when the main question is: “Is this implementation correct according to official guidance?”

This path is for framework, runtime, API, and source-backed implementation checks.

When both are needed

Run them separately and in order

If both review types are needed, do not merge them into one run.

Order: 1) Code Review: Architecture & Boundaries → 2) Code Review: Implementation vs Official Guidance.

Option 1

Code Review: Architecture & Boundaries

Choose this when the main question is about system structure, module or layer boundaries, dependency direction, ownership, interface misuse, state leakage, or minimal structural remediation.

Use this path when the dominant problem is architectural shape rather than standards-backed implementation correctness.

Open procedure

Policy System prompt User prompt

Option 2

Code Review: Implementation vs Official Guidance

Choose this when the main question is about whether code or config changes are correct, framework, library, runtime, or platform guidance, API misuse, version-sensitive implementation issues, or source-backed remediation.

Use this path when the dominant problem is implementation correctness against official guidance.

Open procedure

Policy System prompt User prompt

ChatGPT Projects, GPTs, Skills, files/sources, Custom Instructions, Memory, and runtime prompts. Open mapping → Claude Projects, Project Instructions, Project Knowledge, Skills, and runtime chat input. Open mapping → Gemini Gems, Gem instructions, Knowledge files, Memory, Connected Apps, AI Studio, Gemini API, Files API, File Search, and Vertex AI. Open mapping →

Repository context

Provide the relevant files, module boundaries, config files, tests, and any recent changes that define the review scope.

Official guidance

For implementation review, include the official framework, API, runtime, or platform guidance that the code must be checked against.

Review question

State the exact decision you need from the review: structural boundary diagnosis, implementation correctness, or a two-pass review.

Wrong starting path

Starting with implementation guidance when the real problem is structural.

This usually hides the actual boundary failure.

Using architecture review as style review

Treating architecture review as if it were code-style or framework-guidance review.

The architecture path is about boundaries, ownership, and structural shape.

Merged review contract

Mixing both review types into one run by default.

Run them separately unless there is a deliberate two-pass workflow.

Looking for a mega-prompt

Looking for a single mega-prompt called “code review” instead of choosing the correct path first.

This page is for routing, not for one-size-fits-all execution.