Run the standards-backed implementation review — procedure

Use this guide to review code, configuration, API usage, or design materials against official documentation, standards, or primary vendor guidance.

Purpose

This guide explains how to run a standards-backed implementation review. Use it when implementation choices must be validated against official documentation, standards, or primary vendor guidance. The workflow requires concrete implementation materials, explicit constraints, and authoritative sources or permission to browse for them. It is designed for real review scenarios where code, configuration, API usage, runtime behavior, or design material may be correct only under specific version, platform, framework, or vendor rules.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
Implementation must match official guidance
Use this when code, configuration, API usage, runtime behavior, or design material needs to be checked against official documentation, standards, or primary vendor guidance.
Use case
The issue may be version-sensitive
Use this when the implementation depends on a specific framework, library, runtime, API version, platform, protocol, or compatibility target.
Use case
Findings must be evidence-bound
Use this when every finding must be tied to supplied implementation evidence and inspected authoritative sources.
Use case
A concrete changeset is needed
Use this when the output should identify specific files, configuration entries, excerpts, or implementation deltas rather than broad advice.

Workflow assets

Required workflow assets

Open the prompts, policies, and reference pages needed to run this workflow correctly.

Required prompt
Check implementation against official documentation
Runs the source-backed implementation review and produces context, source applicability, source-bound findings, changeset planning, and confidence.
Type: Workflow template
Belongs in: Runtime prompt layer
Use when: The task is to validate implementation correctness against official documentation, standards, or primary vendor guidance.
Open prompt
Required policy
Check implementation against official guidance — policy
Defines the evidence boundary for standards-backed implementation review.
Type: Engineering review policy
Controls: Source-backed findings, official guidance alignment, version applicability, minimal remediation, and confidence reporting.
Read policy

Implementation procedure

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Runtime prompt layer

    State the implementation review target

    Identify the implementation choice that needs validation: code, configuration, API usage, runtime behavior, platform behavior, protocol handling, or design material.

    Action
    Provide the review goal and define the exact implementation surface under review.
    Verify
    The target is implementation correctness, not architecture classification or broad redesign.

  2. Reference layer

    Provide the implementation materials

    Attach or paste the relevant files, excerpts, configuration, API calls, logs, design material, or documentation excerpts.

    Action
    Keep the materials concrete enough that findings can cite exact files, excerpts, or configuration entries.
    Verify
    The review has inspectable implementation evidence.

  3. Reference layer

    Provide constraints and applicability details

    State the language, framework, library, runtime, platform, API version, deployment target, compatibility target, or non-functional constraint.

    Action
    Include version and runtime details when the guidance may be version-sensitive.
    Verify
    The review can evaluate whether each source applies to the supplied implementation.

  4. Reference layer

    Provide authoritative sources or browsing permission

    Supply official documentation, standards, primary vendor references, or explicit permission to browse for them.

    Action
    Do not rely on memory, informal summaries, or unsupported best-practice claims.
    Verify
    The review has an authoritative source boundary.

  5. Runtime prompt layer

    Run the implementation-review prompt

    Open the public prompt and replace the MATERIALS block with the goal, implementation materials, constraints, and authoritative sources or browsing permission.

    Action
    Ask for context snapshot, sources and applicability, implementation findings, changeset plan, and confidence.
    Verify
    The prompt is applied only to implementation correctness against authoritative guidance.
    Open prompt

  6. Verification layer

    Verify source applicability

    Check whether each cited source actually applies to the supplied version, framework, runtime, platform, protocol, or vendor context.

    Action
    Mark version-sensitive or unmatched guidance as NOT VERIFIED.
    Verify
    No finding depends on a source whose applicability was not established.

  7. Verification layer

    Accept only source-bound findings

    Check that every finding has implementation evidence and authoritative-source support.

    Action
    Reject unsupported findings, speculative improvements, invented source content, and remediation that is not tied to the reviewed material.
    Verify
    The output separates supported findings, missing evidence, required changes, and confidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

Inputs
Goal, materials, constraints, and sources are present
If any required input is missing, the workflow must stop with insufficient evidence.
Evidence
Findings are tied to supplied implementation material
Each finding cites a concrete file, excerpt, configuration entry, API usage, log, or design material that was actually supplied.
Sources
Recommendations are backed by authoritative guidance
Every non-trivial recommendation is supported by official documentation, standards, or primary vendor guidance.
Applicability
Version and runtime applicability are checked
Version-sensitive guidance is applied only when the supplied constraints and inspected source support it.
Scope
The review stays inside implementation correctness
The output does not drift into architecture classification, speculative redesign, full security review, or unrelated code-quality review.
Output
The response follows the required section order
The answer separates context snapshot, sources and applicability, implementation findings, changeset plan, and confidence.

Next step