domains / families / security / spec-to-code-compliance

spec-to-code-compliance

combined

Verifies code implements exactly what documentation specifies for blockchain audits. Use when comparing code against whitepapers, finding gaps between specs and implementation, or performing compliance checks for protocol implementations. Check code against the documentation that specifies it - which requirements hold, which the code contradicts, which are absent, and what the code does that no document mentions. Use when comparing an implementation against a whitepaper, protocol spec, or design document.

When to use

• Verify code implements exactly what documentation specifies
• Audit smart contracts against whitepapers or design documents
• Find gaps between intended behavior and actual implementation
• Identify undocumented code behavior or unimplemented spec claims
• Perform compliance checks for blockchain protocol implementations
• User provides both specification documents AND codebase
• Questions like "does this code match the spec?" or "what's missing from the implementation?"
• Audit engagements requiring spec-to-code alignment analysis

When not to use

• Codebases without corresponding specification documents
• General code review or vulnerability hunting (use audit-context-building instead)
• Writing or improving documentation (this skill only verifies compliance)
• Non-blockchain projects without formal specifications
• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
• Not for code with no documentation of intended behavior. There is nothing to check against, and a requirement inferred from the code is checked against itself. Build the system model first with `audit-context-building`. Not for finding bug…

Skill page

Conflict

The two copies describe the same task but prescribe different, non-interchangeable procedures. The trailofbits copy is a dispatcher: it tells the agent to run a specific slash command and subagent, explains why the work must be fanned out per requirement, and defines a six-verdict output schema with a refutation step. The sickn33 copy is a self-contained, multi-phase audit procedure (Discovery, Normalization, Spec-IR, Code-IR, Alignment) with explicit global rules, a rationalization table, and a confidence-score requirement. Neither copy contains the other's core mechanism (the slash-command dispatch vs. the IR-based line-by-line analysis), so crowning one would hide a real alternative approach.