compliance-checker

Files (6)

• SKILL.md
• classification.md · references/
• cross-framework-mapping.md · references/
• frameworks.md · references/
• output-template.md · references/
• scan-patterns.md · references/

SKILL.md (first lines)

# Compliance Checker

Perform thorough regulatory compliance audits against one or more frameworks, identify gaps, and produce actionable remediation guidance with evidence requirements suitable for certification preparation.

## Contents
- `references/frameworks.md` — the five supported frameworks (GDPR, HIPAA, SOC 2, CCPA, PCI-DSS): scope, key articles/requirements, penalties, and reference links.
- `references/scan-patterns.md` — the seven scan categories, their search patterns, scan execution rules, and common pitfalls to always check.
- `references/classification.md` — compliance status values, risk severity rubric, and the remediation detail fields.
- `references/cross-framework-mapping.md` — control-area-to-framework mapping and the glossary.
- `references/output-template.md` — the full `compliance-report.md` structure, including per-framework gap-analysis tables and evidence packs.

## Workflow

Run the full methodology for every audit. Do not skip steps.

### Phase 1: Discovery and Scoping
1. Identify the target: codebase, infrastructure configuration, business process documentation, or a combination.
2. Determine applicable frameworks from the data types processed, geographic scope, industry, and business model. See `references/frameworks.md`. When none are specified, assess all five and note applicability.
3. Map the data flow: where regulated data enters, how it is processed, where it is stored, and how it exits.
4. Inventory data categories present (PII, PHI, CHD, sensitive PI, special category data).

### Phase 2: Scanning and Evidence Collection
5. Scan each of the seven categories — PII/sensitive data, data retention, encryption, access controls, audit logging, consent management, and data transfer. Apply the search patterns and execution rules in `references/scan-patterns.md`. Record exact file paths, line numbers, and snippets for both positive findings and gaps.

### Phase 3: Gap Analysis
6. Map each finding to specific framework requirements, assign a compliance status, and assign a risk severity to every non-compliant or partial finding. Use the rubric in `references/classification.md`.

### Phase 4: Remediation Planning
7. For each non-compliant or partial finding, produce the remediation detail (description, regulatory reference, current state, required state, steps, evidence, effort, dependencies) per `references/classification.md`. Cross-reference `references/cross-framework-mapping.md` to flag when one action closes gaps across multiple frameworks.

### Phase 5: Report Generation
8. Generate `compliance-report.md` in the project root (or a user-specified location), following the mandatory structure in `references/output-template.md`. Every section is required; if a section has no findings, state that explicitly.

## Behavioral Rules
1. Never fabricate findings. Back every finding with scan evidence. When evidence is absent, mark UNABLE TO ASSESS rather than guess.
2. Be specific. Reference exact file paths, line numbers, function names, and configuration keys.
3. Distinguish technical from organizational controls. Note when a finding requires verifying organizational controls (training, policies, physical security) that code review alone cannot confirm.
4. Consider the full stack: application code, database schemas, infrastructure configuration, CI/CD pipelines, dependency manifests, documentation, and environment configuration.
5. Prioritize actionable findings. Specify exact changes; avoid vague recommendations like "improve security".
6. Respect the scope. Audit only what is provided. Do not assume broader infrastructure without evidence.
7. Account for frameworks and libraries that handle compliance concerns (ORM parameterized queries, framework CSRF protection); credit them as positive findings but verify configuration.
8. Avoid false positives. Missing a marginal finding is better than reporting a non-gap. Err toward accuracy.
9. Cross-reference across frameworks. Note when a single remediation addresses multiple regulations.
10. Date and version everything so the report can be compared against future audits.

## Responding to Requests
- "Audit this codebase" / "check compliance": Confirm which frameworks to focus on (or assess all five), run Phases 1-5, generate `compliance-report.md`, and summarize the most critical findings.
- "Check for [framework]": Focus on that framework, still scan all seven categories, and map findings only to it.
- "Check [category]" (e.g., "check encryption"): Focus the scan on that category and map findings to all applicable frameworks.
- "Are we [requirement] compliant?" (e.g., GDPR Art. 17): Focus on the relevant controls, give a direct assessment with evidence, and offer remediation if gaps exist.
- Business process documentation instead of code: Adapt the methodology to document analysis, focus on policy and procedure requirements, and note that technical controls cannot be verified without codebase access.

From OneWave-AI/claude-skills, MIT.

More from OneWave-AI/claude-skills