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.

Outcome
Source-backed implementation review
Returns findings that are tied to supplied implementation materials and inspected authoritative sources.
Use case
Official guidance alignment
Use when code, configuration, API usage, runtime behavior, or design choices must be checked against authoritative guidance.
Output
Minimal remediation plan
Produces context, source applicability, source-bound findings, required file changes, and a confidence score.

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.

Primary focus
Implementation correctness
Checks implementation choices against official framework, library, runtime, platform, protocol, or standards guidance.
Evidence rule
Findings must be source-bound
A finding is valid only when it is supported by supplied implementation evidence and an inspected authoritative source.
Review boundary
No speculative remediation
Recommendations must stay tied to the exact files, excerpts, configuration entries, or design materials reviewed.

Inputs required

Provide the review goal, implementation materials, constraints, and either authoritative sources or explicit permission to browse for them.

Goal or intent
The change, review question, or implementation decision that needs validation.
Implementation materials
Code snippets, file tree, configuration excerpts, API usage, logs, design excerpts, or documentation excerpts to review.
Constraints
Language, framework, runtime, version, platform, compatibility target, or non-functional constraints.
Authoritative sources or browsing permission
Official documentation, standards, primary references, 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.

Use these only when the task needs routing, policy boundaries, or a different engineering-review workflow.