feat: add HIPAA entrypoint skill

skills/hipaa-compliance/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: hipaa-compliance
+description: HIPAA-specific entrypoint for healthcare privacy and security work. Use when a task is explicitly framed around HIPAA, PHI handling, covered entities, BAAs, breach posture, or US healthcare compliance requirements.
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# HIPAA Compliance
+
+Use this as the HIPAA-specific entrypoint when a task is clearly about US healthcare compliance. This skill intentionally stays thin and canonical:
+
+- `healthcare-phi-compliance` remains the primary implementation skill for PHI/PII handling, data classification, audit logging, encryption, and leak prevention.
+- `healthcare-reviewer` remains the specialized reviewer when code, architecture, or product behavior needs a healthcare-aware second pass.
+- `security-review` still applies for general auth, input-handling, secrets, API, and deployment hardening.
+
+## When to Use
+
+- The request explicitly mentions HIPAA, PHI, covered entities, business associates, or BAAs
+- Building or reviewing US healthcare software that stores, processes, exports, or transmits PHI
+- Assessing whether logging, analytics, LLM prompts, storage, or support workflows create HIPAA exposure
+- Designing patient-facing or clinician-facing systems where minimum necessary access and auditability matter
+
+## How It Works
+
+Treat HIPAA as an overlay on top of the broader healthcare privacy skill:
+
+1. Start with `healthcare-phi-compliance` for the concrete implementation rules.
+2. Apply HIPAA-specific decision gates:
+   - Is this data PHI?
+   - Is this actor a covered entity or business associate?
+   - Does a vendor or model provider require a BAA before touching the data?
+   - Is access limited to the minimum necessary scope?
+   - Are read/write/export events auditable?
+3. Escalate to `healthcare-reviewer` if the task affects patient safety, clinical workflows, or regulated production architecture.
+
+## HIPAA-Specific Guardrails
+
+- Never place PHI in logs, analytics events, crash reports, prompts, or client-visible error strings.
+- Never expose PHI in URLs, browser storage, screenshots, or copied example payloads.
+- Require authenticated access, scoped authorization, and audit trails for PHI reads and writes.
+- Treat third-party SaaS, observability, support tooling, and LLM providers as blocked-by-default until BAA status and data boundaries are clear.
+- Follow minimum necessary access: the right user should only see the smallest PHI slice needed for the task.
+- Prefer opaque internal IDs over names, MRNs, phone numbers, addresses, or other identifiers.
+
+## Examples
+
+### Example 1: Product request framed as HIPAA
+
+User request:
+
+> Add AI-generated visit summaries to our clinician dashboard. We serve US clinics and need to stay HIPAA compliant.
+
+Response pattern:
+
+- Activate `hipaa-compliance`
+- Use `healthcare-phi-compliance` to review PHI movement, logging, storage, and prompt boundaries
+- Verify whether the summarization provider is covered by a BAA before any PHI is sent
+- Escalate to `healthcare-reviewer` if the summaries influence clinical decisions
+
+### Example 2: Vendor/tooling decision
+
+User request:
+
+> Can we send support transcripts and patient messages into our analytics stack?
+
+Response pattern:
+
+- Assume those messages may contain PHI
+- Block the design unless the analytics vendor is approved for HIPAA-bound workloads and the data path is minimized
+- Require redaction or a non-PHI event model when possible
+
+## Related Skills
+
+- `healthcare-phi-compliance`
+- `healthcare-reviewer`
+- `healthcare-emr-patterns`
+- `healthcare-eval-harness`
+- `security-review`