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.

Division of labor: deterministic repo/diff candidate scans live in code-security-review; citation-grounded spec/protocol invariant tracing lives here.

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.
   • Track unspecified behavior separately as an open research question. Inspect SDK defaulting, serialization, retries, fallbacks and error handling to identify a discriminating comparison with raw API behavior. Strange errors can reveal an unexpected implementation path; check configuration, version and a control before attributing security impact.
   • For composed security integrations, name the effective principal and policy input at each hop. Compare what each layer guarantees with what its caller assumes. Key policies, grants, identity policies, delegated services, workload identities and admission controls should be examined only where that target actually uses them.
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.
7. Persist the review. Record notable invariant statuses and candidates as Research Observations via security-observation-intake, and persist cited source excerpts and the invariant matrix as Artifacts through the Evidence Interface (src/server/evidence/artifact-service.ts). Chat output alone evaporates with the turn; cited claims must survive it.

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.