Check implementation against official documentation
Use this prompt when implementation choices must be validated against official documentation, standards, or primary vendor guidance, with source-bound findings and file-specific remediation.
Scope and best-fit use
Use this workflow for implementation correctness against official framework, library, runtime, platform, protocol, standards, or vendor guidance. Keep architecture classification, broad design review, and speculative improvement work in separate workflows.
Inputs required
Provide the review goal, implementation materials, constraints, and either authoritative sources or explicit permission to browse for them.
Copy-ready prompt
Copy this prompt and replace the MATERIALS block with the review goal, implementation materials, constraints, and authoritative sources or browsing permission.
STANDARDS-BACKED IMPLEMENTATION REVIEW
OBJECTIVE
Perform a source-backed implementation review of the provided code/design materials:
- validate the implementation against official documentation, standards, or primary vendor guidance,
- identify correctness, compatibility, reliability, maintainability, performance, or security-control issues that are actually supported by inspected sources,
- produce actionable, file-specific remediation steps.
SCOPE
- Check implementation choices against official framework, library, runtime, platform, protocol, or standards guidance.
- Identify API misuse, configuration problems, version-sensitive mistakes, and regression-sensitive implementation issues.
- Produce source-bound recommendations tied to the exact files or excerpts reviewed.
NON-GOALS
- Do not classify the overall architecture or diagnose broad system-boundary design.
- Do not brainstorm speculative improvements without authoritative support.
- Do not perform a full secure-code-review program unless the request scope and inspected sources explicitly support that review.
INPUT REQUIRED
The supplied materials must include:
- Goal or intent of the change or review
- Materials: code snippets, file tree, config excerpts, or design/doc excerpts
- Constraints: language/framework/runtime/version and any non-functional limits
- Authoritative sources: official documentation, standards, or primary references, OR explicit permission to browse for them
FAIL-CLOSED CONDITIONS
If any required input is missing, output only:
INSUFFICIENT_EVIDENCE: <what is missing>
OUTPUT EXACTLY IN THIS ORDER
A) CONTEXT SNAPSHOT
- Restate the goal, constraints, exact materials reviewed, and the implementation surface under review.
B) SOURCES & APPLICABILITY
- List the authoritative sources actually used.
- State the version/runtime applicability when relevant.
- If version-sensitive guidance cannot be matched to the materials, say NOT VERIFIED.
C) IMPLEMENTATION FINDINGS (SOURCE-BOUND)
For each finding provide:
- ID
- Severity: P0 / P1 / P2
- Category: Correctness / Compatibility / Reliability / Maintainability / Performance / Security Controls
- Evidence: exact file/path/excerpt reference from the provided materials
- Source: exact authoritative source used for the recommendation
- Diagnosis
- Minimal remediation
D) CHANGESET PLAN
- Enumerate required file changes: MODIFY / ADD / REMOVE
- Provide copy/paste replacement blocks when feasible
- Keep the plan minimal and implementation-specific
E) CONFIDENCE
- Provide one confidence score from 0–100 based on evidence completeness, source quality, and source applicability.
MATERIALS START:
"""
Replace this block with:
- goal or intent of the review
- code/config/design excerpts or file paths
- language/framework/runtime/version constraints
- authoritative sources or explicit permission to browse
"""
MATERIALS END.
Related engineering review resources
Use these only when the task needs routing, policy boundaries, or a different engineering-review workflow.