Review Code Against Language and Framework Best Practices

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.

When to use this prompt

Use this prompt to review supplied code for implementation quality while separating official guidance from convention-based recommendations.

Use it when

Code quality and implementation conventions are the main question

Use it when the user needs review of readability, naming, modularity, error handling, dependency use, testability, and alignment with language or framework guidance.

Do not use it when

The task is architecture, security, refactor planning, or test coverage

Use a dedicated architecture-review, security-review, behavior-preserving refactor, or test-coverage workflow when those are the primary review goals.

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.
Do not perform a full architecture review unless a structural issue directly affects the reviewed code.
Do not perform a security review unless the user explicitly asks for security review.
Do not perform behavior-preserving refactor planning unless the user explicitly asks for a refactor plan.
Do not perform test-coverage analysis unless the user explicitly asks for coverage or regression-risk review.

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
"""

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 →

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

No simulation / no fabrication

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

Open component →

Generate beginner-friendly code with assumption checks

Use this workflow when the task is code generation for a beginner and missing assumptions must be checked before writing code.

Open workflow →

Test coverage and regression review

Use this workflow when the next task is checking test coverage, missing scenarios, and regression risk.

Open workflow →

Use this as a runtime code-review prompt