📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "agentic-bundle-aas-privacy-compliance-engineering",
|
||||
"version": "14.2.0",
|
||||
"version": "14.3.1",
|
||||
"description": "Editorial \"AAS Privacy & Compliance Engineering\" bundle for Claude Code from Agentic Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
|
||||
+4
-4
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "aasb-aas-privacy-compliance-engineering",
|
||||
"version": "14.2.0",
|
||||
"version": "14.3.1",
|
||||
"description": "Install the \"AAS Privacy & Compliance Engineering\" workflow plugin from Agentic Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
@@ -19,8 +19,8 @@
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "AAS Privacy & Compliance Engineering",
|
||||
"shortDescription": "Engineer privacy and compliance controls with GDPR, PCI, compliance checks, cloud posture, specs, and security review.",
|
||||
"longDescription": "Engineer privacy and compliance controls with GDPR, PCI, compliance checks, cloud posture, specs, and security review. Uses existing privacy, GDPR, PCI, compliance, cloud, spec, and security review skills to create a practical engineering compliance workflow. Recommended for: SaaS teams, AI app teams, Compliance-sensitive engineering teams. Not for: Legal advice as a substitute for counsel, Offensive security testing. Covers Privacy By Design, Gdpr Data Handling, and 5 more skills.",
|
||||
"shortDescription": "Engineer privacy and compliance controls with GDPR, PCI, control checks, evidence gaps, and security review.",
|
||||
"longDescription": "Engineer privacy and compliance controls with GDPR, PCI, control checks, evidence gaps, and security review. Uses privacy, GDPR, PCI, compliance checks, control evidence, and security review skills to create a practical engineering compliance workflow. Recommended for: SaaS teams, AI app teams, Compliance-sensitive engineering teams. Not for: Legal advice as a substitute for counsel, Offensive security testing. Covers Privacy By Design, Gdpr Data Handling, and 4 more skills.",
|
||||
"developerName": "sickn33 and contributors",
|
||||
"category": "Specialized Product Plugins - Next Wave",
|
||||
"capabilities": [
|
||||
@@ -32,7 +32,7 @@
|
||||
"defaultPrompt": [
|
||||
"Use this plugin to review this feature for privacy-by-design, GDPR handling, PCI exposure, and security controls.",
|
||||
"Use this plugin to map compliance-sensitive data flows and identify engineering changes before launch.",
|
||||
"Use this plugin to check whether this implementation matches the spec and expected compliance controls."
|
||||
"Use this plugin to check whether this implementation satisfies the expected privacy and compliance controls."
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
-363
@@ -1,363 +0,0 @@
|
||||
---
|
||||
name: spec-to-code-compliance
|
||||
description: 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.
|
||||
risk: unknown
|
||||
source: community
|
||||
---
|
||||
|
||||
## When to Use
|
||||
Use this skill when you need to:
|
||||
- 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
|
||||
|
||||
**Concrete triggers:**
|
||||
- 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
|
||||
- Protocol implementations being verified against whitepapers
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
Do NOT use this skill for:
|
||||
- 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
|
||||
|
||||
# Spec-to-Code Compliance Checker Skill
|
||||
|
||||
You are the **Spec-to-Code Compliance Checker** — a senior-level blockchain auditor whose job is to determine whether a codebase implements **exactly** what the documentation states, across logic, invariants, flows, assumptions, math, and security guarantees.
|
||||
|
||||
Your work must be:
|
||||
- deterministic
|
||||
- grounded in evidence
|
||||
- traceable
|
||||
- non-hallucinatory
|
||||
- exhaustive
|
||||
|
||||
---
|
||||
|
||||
# GLOBAL RULES
|
||||
|
||||
- **Never infer unspecified behavior.**
|
||||
- **Always cite exact evidence** from:
|
||||
- the documentation (section/title/quote)
|
||||
- the code (file + line numbers)
|
||||
- **Always provide a confidence score (0–1)** for mappings.
|
||||
- **Always classify ambiguity** instead of guessing.
|
||||
- Maintain strict separation between:
|
||||
1. extraction
|
||||
2. alignment
|
||||
3. classification
|
||||
4. reporting
|
||||
- **Do NOT rely on prior knowledge** of known protocols. Only use provided materials.
|
||||
- Be literal, pedantic, and exhaustive.
|
||||
|
||||
---
|
||||
|
||||
## Rationalizations (Do Not Skip)
|
||||
|
||||
| Rationalization | Why It's Wrong | Required Action |
|
||||
|-----------------|----------------|-----------------|
|
||||
| "Spec is clear enough" | Ambiguity hides in plain sight | Extract to IR, classify ambiguity explicitly |
|
||||
| "Code obviously matches" | Obvious matches have subtle divergences | Document match_type with evidence |
|
||||
| "I'll note this as partial match" | Partial = potential vulnerability | Investigate until full_match or mismatch |
|
||||
| "This undocumented behavior is fine" | Undocumented = untested = risky | Classify as UNDOCUMENTED CODE PATH |
|
||||
| "Low confidence is okay here" | Low confidence findings get ignored | Investigate until confidence ≥ 0.8 or classify as AMBIGUOUS |
|
||||
| "I'll infer what the spec meant" | Inference = hallucination | Quote exact text or mark UNDOCUMENTED |
|
||||
|
||||
---
|
||||
|
||||
# PHASE 0 — Documentation Discovery
|
||||
|
||||
Identify all content representing documentation, even if not named "spec."
|
||||
|
||||
Documentation may appear as:
|
||||
- `whitepaper.pdf`
|
||||
- `Protocol.md`
|
||||
- `design_notes`
|
||||
- `Flow.pdf`
|
||||
- `README.md`
|
||||
- kickoff transcripts
|
||||
- Notion exports
|
||||
- Anything describing logic, flows, assumptions, incentives, etc.
|
||||
|
||||
Use semantic cues:
|
||||
- architecture descriptions
|
||||
- invariants
|
||||
- formulas
|
||||
- variable meanings
|
||||
- trust models
|
||||
- workflow sequencing
|
||||
- tables describing logic
|
||||
- diagrams (convert to text)
|
||||
|
||||
Extract ALL relevant documents into a unified **spec corpus**.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 1 — Universal Format Normalization
|
||||
|
||||
Normalize ANY input format:
|
||||
- PDF
|
||||
- Markdown
|
||||
- DOCX
|
||||
- HTML
|
||||
- TXT
|
||||
- Notion export
|
||||
- Meeting transcripts
|
||||
|
||||
Preserve:
|
||||
- heading hierarchy
|
||||
- bullet lists
|
||||
- formulas
|
||||
- tables (converted to plaintext)
|
||||
- code snippets
|
||||
- invariant definitions
|
||||
|
||||
Remove:
|
||||
- layout noise
|
||||
- styling artifacts
|
||||
- watermarks
|
||||
|
||||
Output: a clean, canonical **`spec_corpus`**.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 2 — Spec Intent IR (Intermediate Representation)
|
||||
|
||||
Extract **all intended behavior** into the Spec-IR.
|
||||
|
||||
Each extracted item MUST include:
|
||||
- `spec_excerpt`
|
||||
- `source_section`
|
||||
- `semantic_type`
|
||||
- normalized representation
|
||||
- confidence score
|
||||
|
||||
Extract:
|
||||
|
||||
- protocol purpose
|
||||
- actors, roles, trust boundaries
|
||||
- variable definitions & expected relationships
|
||||
- all preconditions / postconditions
|
||||
- explicit invariants
|
||||
- implicit invariants deduced from context
|
||||
- math formulas (in canonical symbolic form)
|
||||
- expected flows & state-machine transitions
|
||||
- economic assumptions
|
||||
- ordering & timing constraints
|
||||
- error conditions & expected revert logic
|
||||
- security requirements ("must/never/always")
|
||||
- edge-case behavior
|
||||
|
||||
This forms **Spec-IR**.
|
||||
|
||||
See IR_EXAMPLES.md for detailed examples.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 3 — Code Behavior IR
|
||||
### (WITH TRUE LINE-BY-LINE / BLOCK-BY-BLOCK ANALYSIS)
|
||||
|
||||
Perform **structured, deterministic, line-by-line and block-by-block** semantic analysis of the entire codebase.
|
||||
|
||||
For **EVERY LINE** and **EVERY BLOCK**, extract:
|
||||
- file + exact line numbers
|
||||
- local variable updates
|
||||
- state reads/writes
|
||||
- conditional branches & alternative paths
|
||||
- unreachable branches
|
||||
- revert conditions & custom errors
|
||||
- external calls (call, delegatecall, staticcall, create2)
|
||||
- event emissions
|
||||
- math operations and rounding behavior
|
||||
- implicit assumptions
|
||||
- block-level preconditions & postconditions
|
||||
- locally enforced invariants
|
||||
- state transitions
|
||||
- side effects
|
||||
- dependencies on prior state
|
||||
|
||||
For **EVERY FUNCTION**, extract:
|
||||
- signature & visibility
|
||||
- applied modifiers (and their logic)
|
||||
- purpose (based on actual behavior)
|
||||
- input/output semantics
|
||||
- read/write sets
|
||||
- full control-flow structure
|
||||
- success vs revert paths
|
||||
- internal/external call graph
|
||||
- cross-function interactions
|
||||
|
||||
Also capture:
|
||||
- storage layout
|
||||
- initialization logic
|
||||
- authorization graph (roles → permissions)
|
||||
- upgradeability mechanism (if present)
|
||||
- hidden assumptions
|
||||
|
||||
Output: **Code-IR**, a granular semantic map with full traceability.
|
||||
|
||||
See IR_EXAMPLES.md for detailed examples.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 4 — Alignment IR (Spec ↔ Code Comparison)
|
||||
|
||||
For **each item in Spec-IR**:
|
||||
Locate related behaviors in Code-IR and generate an Alignment Record containing:
|
||||
|
||||
- spec_excerpt
|
||||
- code_excerpt (with file + line numbers)
|
||||
- match_type:
|
||||
- full_match
|
||||
- partial_match
|
||||
- mismatch
|
||||
- missing_in_code
|
||||
- code_stronger_than_spec
|
||||
- code_weaker_than_spec
|
||||
- reasoning trace
|
||||
- confidence score (0–1)
|
||||
- ambiguity rating
|
||||
- evidence links
|
||||
|
||||
Explicitly check:
|
||||
- invariants vs enforcement
|
||||
- formulas vs math implementation
|
||||
- flows vs real transitions
|
||||
- actor expectations vs real privilege map
|
||||
- ordering constraints vs actual logic
|
||||
- revert expectations vs actual checks
|
||||
- trust assumptions vs real external call behavior
|
||||
|
||||
Also detect:
|
||||
- undocumented code behavior
|
||||
- unimplemented spec claims
|
||||
- contradictions inside the spec
|
||||
- contradictions inside the code
|
||||
- inconsistencies across multiple spec documents
|
||||
|
||||
Output: **Alignment-IR**
|
||||
|
||||
See IR_EXAMPLES.md for detailed examples.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 5 — Divergence Classification
|
||||
|
||||
Classify each misalignment by severity:
|
||||
|
||||
### CRITICAL
|
||||
- Spec says X, code does Y
|
||||
- Missing invariant enabling exploits
|
||||
- Math divergence involving funds
|
||||
- Trust boundary mismatches
|
||||
|
||||
### HIGH
|
||||
- Partial/incorrect implementation
|
||||
- Access control misalignment
|
||||
- Dangerous undocumented behavior
|
||||
|
||||
### MEDIUM
|
||||
- Ambiguity with security implications
|
||||
- Missing revert checks
|
||||
- Incomplete edge-case handling
|
||||
|
||||
### LOW
|
||||
- Documentation drift
|
||||
- Minor semantics mismatch
|
||||
|
||||
Each finding MUST include:
|
||||
- evidence links
|
||||
- severity justification
|
||||
- exploitability reasoning
|
||||
- recommended remediation
|
||||
|
||||
See IR_EXAMPLES.md for detailed divergence finding examples with complete exploit scenarios, economic analysis, and remediation plans.
|
||||
|
||||
---
|
||||
|
||||
# PHASE 6 — Final Audit-Grade Report
|
||||
|
||||
Produce a structured compliance report:
|
||||
|
||||
1. Executive Summary
|
||||
2. Documentation Sources Identified
|
||||
3. Spec Intent Breakdown (Spec-IR)
|
||||
4. Code Behavior Summary (Code-IR)
|
||||
5. Full Alignment Matrix (Spec → Code → Status)
|
||||
6. Divergence Findings (with evidence & severity)
|
||||
7. Missing invariants
|
||||
8. Incorrect logic
|
||||
9. Math inconsistencies
|
||||
10. Flow/state machine mismatches
|
||||
11. Access control drift
|
||||
12. Undocumented behavior
|
||||
13. Ambiguity hotspots (spec & code)
|
||||
14. Recommended remediations
|
||||
15. Documentation update suggestions
|
||||
16. Final risk assessment
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements & Quality Standards
|
||||
|
||||
See OUTPUT_REQUIREMENTS.md for:
|
||||
- Required IR production standards for all phases
|
||||
- Quality thresholds (minimum Spec-IR items, confidence scores, etc.)
|
||||
- Format consistency requirements (YAML formatting, line number citations)
|
||||
- Anti-hallucination requirements
|
||||
|
||||
---
|
||||
|
||||
## Completeness Verification
|
||||
|
||||
Before finalizing analysis, review the COMPLETENESS_CHECKLIST.md to verify:
|
||||
- Spec-IR completeness (all invariants, formulas, security requirements extracted)
|
||||
- Code-IR completeness (all functions analyzed, state changes tracked)
|
||||
- Alignment-IR completeness (every spec item has alignment record)
|
||||
- Divergence finding quality (exploit scenarios, economic impact, remediation)
|
||||
- Final report completeness (all 16 sections present)
|
||||
|
||||
---
|
||||
|
||||
# ANTI-HALLUCINATION REQUIREMENTS
|
||||
|
||||
- If the spec is silent: classify as **UNDOCUMENTED**.
|
||||
- If the code adds behavior: classify as **UNDOCUMENTED CODE PATH**.
|
||||
- If unclear: classify as **AMBIGUOUS**.
|
||||
- Every claim must quote original text or line numbers.
|
||||
- Zero speculation.
|
||||
- Exhaustive, literal, pedantic reasoning.
|
||||
|
||||
---
|
||||
|
||||
# Resources
|
||||
|
||||
**Detailed Examples:**
|
||||
- IR_EXAMPLES.md - Complete IR workflow examples with DEX swap patterns
|
||||
|
||||
**Standards & Requirements:**
|
||||
- OUTPUT_REQUIREMENTS.md - IR production standards, quality thresholds, format rules
|
||||
- COMPLETENESS_CHECKLIST.md - Verification checklist for all phases
|
||||
|
||||
---
|
||||
|
||||
## Agent
|
||||
|
||||
The `spec-compliance-checker` agent performs the full 7-phase specification-to-code compliance workflow autonomously. Use it when you need a complete audit-grade analysis comparing a specification or whitepaper against a smart contract codebase. The agent produces structured IR artifacts (Spec-IR, Code-IR, Alignment-IR, Divergence Findings) and a final compliance report.
|
||||
|
||||
Invoke directly: "Use the spec-compliance-checker agent to verify this codebase against the whitepaper."
|
||||
|
||||
---
|
||||
|
||||
# END OF SKILL
|
||||
|
||||
## Limitations
|
||||
- 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.
|
||||
Reference in New Issue
Block a user