Review code against language and framework best practices

Use this prompt when code needs a focused quality review against supplied project context, language conventions, framework expectations, and official guidance when available.

Outcome
Code-quality review
Returns readability issues, maintainability risks, naming problems, modularity concerns, error-handling gaps, dependency concerns, and testability gaps.
Use case
Implementation-quality review
Use when the main question is whether the code is clear, maintainable, idiomatic for the supplied context, and aligned with relevant guidance.
Output
Evidence-separated findings
Separates official-guidance findings, convention-based findings, required fixes, optional improvements, and missing evidence.

Scope and best-fit use

Use this prompt when the primary goal is implementation-quality review against language, framework, library, and maintainability expectations.

Primary focus
Implementation quality and best-practice alignment
Use this prompt to review readability, naming, modularity, error handling, dependency use, testability, maintainability, and alignment with supplied language or framework guidance.
May also surface
Visible architecture, layering, or security concerns
The review may flag architecture, boundary, layering, or security issues when they are visible in the supplied code, but those are secondary findings rather than the main review objective.
Use a dedicated workflow when
Architecture, security, refactor planning, or test coverage is the primary goal
Use the related architecture, security, behavior-preserving refactor, or test-coverage workflow when the task requires a deeper review in one of those areas.

Inputs required

Provide the code, technical context, review target, and any official guidance that should be used. The prompt should not invent project files, dependencies, framework behavior, runtime output, or test results.

Code to review
The function, file, module, component, configuration, or relevant code excerpt that needs review.
Technical context
Language, framework, runtime, library, API, platform, package manager, and project constraints when available.
Review target
What should be checked: readability, naming, modularity, error handling, dependency use, framework conventions, tests, or maintainability.

Copy-ready prompt

Copy the prompt and replace the MATERIALS block with the code, technical context, constraints, and any official guidance that should be used.

Review code against language and framework best practices.

TASK:
Review the supplied code for code quality, readability, maintainability, naming, modularity, error handling, dependency use, testability, and alignment with the relevant language, framework, runtime, library, API, or platform guidance.

REVIEW SCOPE:
Focus on implementation quality and maintainability.

EVIDENCE RULES:
- Base findings on the supplied code, supplied project context, and official guidance that is supplied or explicitly available.
- Do not invent project files, dependencies, framework behavior, runtime output, test results, logs, defects, or pass/fail status.
- If a finding depends on missing context, mark it as INSUFFICIENT_EVIDENCE.
- If a recommendation is based on a general convention rather than supplied official guidance, label it as CONVENTION_BASED.
- If official language or framework guidance is required but not supplied or available, state what guidance is missing.
- Separate required fixes from optional improvements.

REVIEW CHECKS:
- Readability and naming
- Function, module, or component responsibility
- Control-flow clarity
- Error handling
- Input validation when relevant
- Dependency and import use
- Framework or API conventions
- Configuration use when relevant
- Testability
- Existing tests or missing test signals
- Maintainability risks
- Unnecessary complexity
- Visible dead, duplicated, or unclear code

OUTPUT:
A) Review summary
B) Context and scope used
C) Required fixes
D) Official-guidance findings
E) Convention-based findings
F) Maintainability risks
G) Testability and testing gaps
H) Optional improvements
I) Missing evidence or missing official guidance
J) Confidence

MATERIALS:
"""
Replace this block with:
- code to review
- language/framework/runtime, if known
- relevant official guidance, if supplied
- project constraints, if relevant
- tests or examples, if available
- specific review goal, if any
"""

Use this as a runtime code-review prompt

Paste the code and technical context into the prompt. Keep stable no-fabrication, code-review, and project-specific rules in the instruction layer.

Next steps

Use these related workflows when the task needs assumption checks, refactor planning, test coverage review, or stricter evidence control.