Review Architecture and Boundaries

Outcome

Architecture-boundary review

Returns architecture classification when supported, boundary findings, evidence from supplied materials, and a minimal structural changeset plan.

Use case

Structure-first engineering review

Use when the main concern is whether system structure, layering, ownership, dependency direction, or module boundaries are correct.

Output

Evidence-based structural findings

Separates context, architecture classification, boundary findings, required structural changes, and confidence.

Scope and best-fit use

Use this prompt for architecture and boundary review. Do not use it as a broad implementation best-practice sweep, secure code review, or performance-tuning workflow.

Primary focus

Architecture, layering, and boundaries

Review observed architecture, dependency direction, module leakage, interface contracts, state ownership, coupling, and boundary drift only from supplied materials.

Fail-closed rule

No unsupported architecture claims

If the supplied materials do not support architecture classification or a finding, the output must mark it as NOT VERIFIED or INSUFFICIENT_EVIDENCE.

Use another workflow when

Implementation guidance, security, performance, or refactor planning is primary

Use the standards-backed implementation review, security-review workflow, performance review, or behavior-preserving refactor prompt when that is the main task.

Inputs required

Provide the review goal, inspected materials, and technical constraints. The prompt should not infer hidden files, hidden architecture, runtime behavior, tests, logs, or target architecture that was not supplied.

Review goal

What should be evaluated: observed architecture, layering, dependency direction, state ownership, module boundaries, interface ownership, or a specific structural concern.

Materials to inspect

Code snippets, file tree, module map, design notes, architecture diagrams, interface contracts, configuration excerpts, or relevant repository excerpts.

Technical constraints

Language, framework, runtime, platform, deployment constraints, intended architecture, boundary rules, or ownership expectations when available.

Copy-ready prompt

Copy the prompt and replace the MATERIALS block with the review goal, files or excerpts, constraints, and optional intended architecture or boundary rules.

Run an architecture boundary review on the supplied materials.

HARD RULE:
Do not simulate.

TASK:
Perform an architecture-focused review of the provided code or design materials:
- classify the observed architecture only if the materials support it
- identify boundary, layering, dependency-direction, interface, coupling, and state-ownership issues
- propose minimal structural remediation steps tied to the inspected materials

REVIEW SCOPE:
- Architecture classification only when evidence supports it
- Layering violations
- Dependency direction problems
- Module leakage
- Interface contract misuse or drift
- State ownership ambiguity
- Coupling across boundaries
- Minimal structural remediation planning tied to the files or excerpts reviewed

NON-GOALS:
- Do not run a general framework, library, or language best-practice sweep.
- Do not perform a secure code review.
- Do not perform a performance-tuning review.
- Do not rewrite whole subsystems.
- Do not invent a target architecture that is not evidenced in the materials.

REQUIRED INPUTS:
- Goal or intent of the review
- Materials: code snippets, file tree, module map, diagrams, or design excerpts
- Constraints: language, framework, runtime, platform, intended architecture, or boundary rules when available

OPTIONAL INPUTS:
- Intended architecture or boundary rules, if the observed implementation should be checked against an explicit target design
- Ownership expectations for modules, interfaces, state, APIs, or persistence boundaries
- Authoritative sources, only if a recommendation must be justified against an external rule, framework convention, or standard

FAIL-CLOSED CONDITIONS:
If any required input is missing, output only:
INSUFFICIENT_EVIDENCE: <what is missing>

EVIDENCE RULES:
- Base findings only on the supplied materials and explicitly supplied authoritative sources.
- Do not invent files, modules, dependencies, architecture style, runtime behavior, logs, tests, defects, or hidden project context.
- If architecture classification is not supported, write NOT VERIFIED and state what evidence is missing.
- If a recommendation depends on an external convention or standard and no authoritative source was supplied or inspected, mark that recommendation NOT VERIFIED.
- Keep every remediation step minimal and tied to a concrete finding.

OUTPUT EXACTLY IN THIS ORDER:
A) CONTEXT SNAPSHOT
- Restate the goal, constraints, and exact materials reviewed.

B) ARCHITECTURE CLASSIFICATION (EVIDENCE-BASED)
- Classify the architecture only if the materials support it.
- List 3–10 concrete evidence points.
- If classification is not supportable, write NOT VERIFIED and explain what is missing.

C) BOUNDARY FINDINGS
For each finding provide:
- ID
- Severity: P0 / P1 / P2
- Category: Layering / Dependency Direction / Boundary Leakage / Interface Contract / State Ownership / Coupling
- Evidence: exact file, path, excerpt, diagram element, or supplied material reference
- Why this is a boundary or architecture problem
- Minimal structural remediation
- Source status: SUPPLIED_EVIDENCE / AUTHORITATIVE_SOURCE_SUPPLIED / NOT VERIFIED

D) CHANGESET PLAN
- Enumerate required file changes as MODIFY / ADD / REMOVE.
- Keep the plan minimal and structural.
- Provide copy/paste replacement blocks when feasible.
- Do not propose broad rewrites unless the supplied materials prove they are required.

E) CONFIDENCE
- Provide one confidence score from 0–100 based on evidence completeness and architectural clarity.
- List the main evidence limits that lower confidence.

MATERIALS:
"""
Replace this block with:
- review goal
- file tree or module map, if available
- relevant code excerpts
- relevant design or architecture excerpts
- language, framework, runtime, and platform constraints
- intended architecture or boundary rules, if any
- ownership expectations, if any
- specific concern to investigate, if any
"""

ChatGPT Projects, GPTs, Skills, files/sources, Custom Instructions, Memory, and runtime prompts. Open mapping → Claude Projects, Project Instructions, Project Knowledge, Skills, Claude Code surfaces, 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 → API / internal systems System/developer instructions, retrieval, tools, orchestration, approvals, validation, evals, logging, and application state. Open mapping →

Use these related workflows when the task needs implementation-guidance review, code-quality review, test-impact review, or stronger no-fabrication control.

Architecture boundary review policy

Use this policy to confirm that the task is architecture and boundary review rather than implementation guidance, security review, or performance review.

Read policy →

Code review guide

Use this guide when you need to choose between architecture review, implementation guidance review, test coverage review, regression review, code quality review, or refactor planning.

Open guide →

Review code against language and framework best practices

Use this workflow when the primary task is implementation quality, readability, maintainability, naming, modularity, error handling, dependency use, or framework guidance.

Open workflow →

No simulation / no fabrication

Use this component when the assistant must not invent project files, dependencies, runtime behavior, command output, test results, or unsupported architecture claims.

Open component →