spec-implementation-review

name	spec-implementation-review
description	Passive, citation-grounded review of security-relevant specifications, protocols, standards, APIs, and implementations. Use when a reviewer must trace external preconditions and invariants into source code without treating a cited claim as proof of a vulnerability.

Spec-Implementation Review

Use this skill when security depends on a protocol property, formal precondition, API contract, standard, parser grammar, authorization rule, sandbox boundary, distributed-systems guarantee, or optimization condition.

Ground Rules

• Work passively unless the user explicitly authorizes build, test, shell, network, browser, or mutation actions.
• Use primary sources whenever possible: standards, specifications, original papers, official API documentation, source repositories, security advisories, or maintainer statements. Record a stable URL, version/commit/section, and concise claim.
• A citation establishes what the source requires; source code establishes what the implementation does. Do not let either substitute for the other.
• Keep findings generic and evidence-backed. A mismatch is a Code Review Candidate until independent validation establishes impact.
• Do not copy target-specific advisories, vulnerability paths, payloads, or hidden benchmark facts into reusable prompts, skills, or candidate-visible eval material.

Workflow

1. Define the contract boundary. Name the Subject, implementation version, relevant modules, caller/callee boundary, and any fast or fallback paths.
2. Extract requirements. For each source claim, record the exact invariant or precondition, source URL/version/section, and why the implementation relies on it.
3. Trace to code. Link each requirement to source files, symbols, guards, tests, and call paths. Inspect both optimized/delegated and slow/fallback behavior.
4. Classify each invariant. Use exactly one status:
   • enforced: a reachable guard or construction establishes the requirement on every relevant path.
   • partially_enforced: enforcement exists but a relevant caller, fast path, fallback, error path, or input shape is not covered.
   • not-located: the review found no implementation evidence establishing the requirement; this is not proof that it is absent.
   • not-applicable: the cited requirement does not apply to this version, boundary, or use case; explain why.
5. Create candidates conservatively. Create a passive candidate only for partially_enforced or not-located when a cited requirement conflicts with concrete implementation evidence. Include the counterexample shape in abstract terms, not an exploit recipe.
6. Queue independent validation. Require a source-to-guard trace, a control case, and a clean-environment oracle before promotion. Active reproduction remains approval-gated.

Output

Return:

• Scope: Subject, version/commit, sources, and allowed actions.
• Invariant Matrix: invariant, primary citation, implementation evidence, status, and confidence.
• Module Contract Cards: inputs, assumptions, guarantees, delegated responsibilities, optimized/fallback paths, and evidence artifacts.
• Composition Tasks: cross-module assumptions that need source-to-guard tracing.
• Candidates: only evidence-backed mismatches, marked draft with validation requirements.
• No-Finding Coverage: requirements traced and enforced, plus limitations.