@funnycode/myclaude 0.1.76 → 0.1.78

package/seed/marketplaces/ecc/skills/healthcare-phi-compliance/SKILL.md

@@ -1,145 +1,145 @@
----
-name: healthcare-phi-compliance
-description: Protected Health Information (PHI) and Personally Identifiable Information (PII) compliance patterns for healthcare applications. Covers data classification, access control, audit trails, encryption, and common leak vectors.
-origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
-version: "1.0.0"
----
-
-# Healthcare PHI/PII Compliance Patterns
-
-Patterns for protecting patient data, clinician data, and financial data in healthcare applications. Applicable to HIPAA (US), DISHA (India), GDPR (EU), and general healthcare data protection.
-
-## When to Use
-
-- Building any feature that touches patient records
-- Implementing access control or authentication for clinical systems
-- Designing database schemas for healthcare data
-- Building APIs that return patient or clinician data
-- Implementing audit trails or logging
-- Reviewing code for data exposure vulnerabilities
-- Setting up Row-Level Security (RLS) for multi-tenant healthcare systems
-
-## How It Works
-
-Healthcare data protection operates on three layers: **classification** (what is sensitive), **access control** (who can see it), and **audit** (who did see it).
-
-### Data Classification
-
-**PHI (Protected Health Information)** — any data that can identify a patient AND relates to their health: patient name, date of birth, address, phone, email, national ID numbers (SSN, Aadhaar, NHS number), medical record numbers, diagnoses, medications, lab results, imaging, insurance policy and claim details, appointment and admission records, or any combination of the above.
-
-**PII (Non-patient-sensitive data)** in healthcare systems: clinician/staff personal details, doctor fee structures and payout amounts, employee salary and bank details, vendor payment information.
-
-### Access Control: Row-Level Security
-
-```sql
-ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
-
--- Scope access by facility
-CREATE POLICY "staff_read_own_facility"
-  ON patients FOR SELECT TO authenticated
-  USING (facility_id IN (
-    SELECT facility_id FROM staff_assignments
-    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
-  ));
-
--- Audit log: insert-only (tamper-proof)
-CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
-  TO authenticated WITH CHECK (user_id = auth.uid());
-CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
-CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);
-```
-
-### Audit Trail
-
-Every PHI access or modification must be logged:
-
-```typescript
-interface AuditEntry {
-  timestamp: string;
-  user_id: string;
-  patient_id: string;
-  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
-  resource_type: string;
-  resource_id: string;
-  changes?: { before: object; after: object };
-  ip_address: string;
-  session_id: string;
-}
-```
-
-### Common Leak Vectors
-
-**Error messages:** Never include patient-identifying data in error messages thrown to the client. Log details server-side only.
-
-**Console output:** Never log full patient objects. Use opaque internal record IDs (UUIDs) — not medical record numbers, national IDs, or names.
-
-**URL parameters:** Never put patient-identifying data in query strings or path segments that could appear in logs or browser history. Use opaque UUIDs only.
-
-**Browser storage:** Never store PHI in localStorage or sessionStorage. Keep PHI in memory only, fetch on demand.
-
-**Service role keys:** Never use the service_role key in client-side code. Always use the anon/publishable key and let RLS enforce access.
-
-**Logs and monitoring:** Never log full patient records. Use opaque record IDs only (not medical record numbers). Sanitize stack traces before sending to error tracking services.
-
-### Database Schema Tagging
-
-Mark PHI/PII columns at the schema level:
-
-```sql
-COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
-COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
-COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
-COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';
-```
-
-### Deployment Checklist
-
-Before every deployment:
-- No PHI in error messages or stack traces
-- No PHI in console.log/console.error
-- No PHI in URL parameters
-- No PHI in browser storage
-- No service_role key in client code
-- RLS enabled on all PHI/PII tables
-- Audit trail for all data modifications
-- Session timeout configured
-- API authentication on all PHI endpoints
-- Cross-facility data isolation verified
-
-## Examples
-
-### Example 1: Safe vs Unsafe Error Handling
-
-```typescript
-// BAD — leaks PHI in error
-throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
-
-// GOOD — generic error, details logged server-side with opaque IDs only
-logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
-throw new Error('Record not found');
-```
-
-### Example 2: RLS Policy for Multi-Facility Isolation
-
-```sql
--- Doctor at Facility A cannot see Facility B patients
-CREATE POLICY "facility_isolation"
-  ON patients FOR SELECT TO authenticated
-  USING (facility_id IN (
-    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
-  ));
-
--- Test: login as doctor-facility-a, query facility-b patients
--- Expected: 0 rows returned
-```
-
-### Example 3: Safe Logging
-
-```typescript
-// BAD — logs identifiable patient data
-console.log('Processing patient:', patient);
-
-// GOOD — logs only opaque internal record ID
-console.log('Processing record:', patient.id);
-// Note: even patient.id should be an opaque UUID, not a medical record number
-```
+---
+name: healthcare-phi-compliance
+description: Protected Health Information (PHI) and Personally Identifiable Information (PII) compliance patterns for healthcare applications. Covers data classification, access control, audit trails, encryption, and common leak vectors.
+origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+version: "1.0.0"
+---
+
+# Healthcare PHI/PII Compliance Patterns
+
+Patterns for protecting patient data, clinician data, and financial data in healthcare applications. Applicable to HIPAA (US), DISHA (India), GDPR (EU), and general healthcare data protection.
+
+## When to Use
+
+- Building any feature that touches patient records
+- Implementing access control or authentication for clinical systems
+- Designing database schemas for healthcare data
+- Building APIs that return patient or clinician data
+- Implementing audit trails or logging
+- Reviewing code for data exposure vulnerabilities
+- Setting up Row-Level Security (RLS) for multi-tenant healthcare systems
+
+## How It Works
+
+Healthcare data protection operates on three layers: **classification** (what is sensitive), **access control** (who can see it), and **audit** (who did see it).
+
+### Data Classification
+
+**PHI (Protected Health Information)** — any data that can identify a patient AND relates to their health: patient name, date of birth, address, phone, email, national ID numbers (SSN, Aadhaar, NHS number), medical record numbers, diagnoses, medications, lab results, imaging, insurance policy and claim details, appointment and admission records, or any combination of the above.
+
+**PII (Non-patient-sensitive data)** in healthcare systems: clinician/staff personal details, doctor fee structures and payout amounts, employee salary and bank details, vendor payment information.
+
+### Access Control: Row-Level Security
+
+```sql
+ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
+
+-- Scope access by facility
+CREATE POLICY "staff_read_own_facility"
+  ON patients FOR SELECT TO authenticated
+  USING (facility_id IN (
+    SELECT facility_id FROM staff_assignments
+    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
+  ));
+
+-- Audit log: insert-only (tamper-proof)
+CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
+  TO authenticated WITH CHECK (user_id = auth.uid());
+CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
+CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);
+```
+
+### Audit Trail
+
+Every PHI access or modification must be logged:
+
+```typescript
+interface AuditEntry {
+  timestamp: string;
+  user_id: string;
+  patient_id: string;
+  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
+  resource_type: string;
+  resource_id: string;
+  changes?: { before: object; after: object };
+  ip_address: string;
+  session_id: string;
+}
+```
+
+### Common Leak Vectors
+
+**Error messages:** Never include patient-identifying data in error messages thrown to the client. Log details server-side only.
+
+**Console output:** Never log full patient objects. Use opaque internal record IDs (UUIDs) — not medical record numbers, national IDs, or names.
+
+**URL parameters:** Never put patient-identifying data in query strings or path segments that could appear in logs or browser history. Use opaque UUIDs only.
+
+**Browser storage:** Never store PHI in localStorage or sessionStorage. Keep PHI in memory only, fetch on demand.
+
+**Service role keys:** Never use the service_role key in client-side code. Always use the anon/publishable key and let RLS enforce access.
+
+**Logs and monitoring:** Never log full patient records. Use opaque record IDs only (not medical record numbers). Sanitize stack traces before sending to error tracking services.
+
+### Database Schema Tagging
+
+Mark PHI/PII columns at the schema level:
+
+```sql
+COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
+COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
+COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
+COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';
+```
+
+### Deployment Checklist
+
+Before every deployment:
+- No PHI in error messages or stack traces
+- No PHI in console.log/console.error
+- No PHI in URL parameters
+- No PHI in browser storage
+- No service_role key in client code
+- RLS enabled on all PHI/PII tables
+- Audit trail for all data modifications
+- Session timeout configured
+- API authentication on all PHI endpoints
+- Cross-facility data isolation verified
+
+## Examples
+
+### Example 1: Safe vs Unsafe Error Handling
+
+```typescript
+// BAD — leaks PHI in error
+throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
+
+// GOOD — generic error, details logged server-side with opaque IDs only
+logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
+throw new Error('Record not found');
+```
+
+### Example 2: RLS Policy for Multi-Facility Isolation
+
+```sql
+-- Doctor at Facility A cannot see Facility B patients
+CREATE POLICY "facility_isolation"
+  ON patients FOR SELECT TO authenticated
+  USING (facility_id IN (
+    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
+  ));
+
+-- Test: login as doctor-facility-a, query facility-b patients
+-- Expected: 0 rows returned
+```
+
+### Example 3: Safe Logging
+
+```typescript
+// BAD — logs identifiable patient data
+console.log('Processing patient:', patient);
+
+// GOOD — logs only opaque internal record ID
+console.log('Processing record:', patient.id);
+// Note: even patient.id should be an opaque UUID, not a medical record number
+```

package/seed/marketplaces/ecc/skills/hermes-imports/SKILL.md

@@ -1,88 +1,88 @@
----
-name: hermes-imports
-description: Convert local Hermes operator workflows into sanitized ECC skills and release-pack artifacts. Use when preparing a Hermes workflow for public ECC reuse without leaking private workspace state, credentials, or local-only paths.
-origin: ECC
----
-
-# Hermes Imports
-
-Use this skill when turning a repeated Hermes workflow into something safe to ship in ECC.
-
-Hermes is the operator shell. ECC is the reusable workflow layer. Imports should move stable patterns from Hermes into ECC without moving private state.
-
-## When To Use
-
-- A Hermes workflow has repeated enough times to become reusable.
-- A local operator prompt should become a public ECC skill.
-- A launch, content, research, or engineering workflow needs sanitized handoff docs.
-- A workflow mentions local paths, credentials, personal datasets, or private account names that must be removed before publication.
-
-## Import Rules
-
-- Convert local paths to repo-relative paths or placeholders.
-- Replace live account names with role labels such as `operator`, `default profile`, or `workspace owner`.
-- Describe credential requirements by provider name only.
-- Keep examples narrow and operational.
-- Do not ship raw workspace exports, tokens, OAuth files, health data, CRM data, or finance data.
-- If the workflow requires private state to make sense, keep it local.
-
-## Sanitization Checklist
-
-Before committing an imported workflow, scan for:
-
-- absolute paths such as `/Users/...`
-- `~/.hermes` paths unless the doc is explicitly explaining local setup
-- API keys, tokens, cookies, OAuth files, or bearer strings
-- phone numbers, private email addresses, and personal contact graphs
-- client names, family names, or account names that are not already public
-- revenue, health, or CRM details
-- raw logs that include tool output from private systems
-
-## Conversion Pattern
-
-1. Identify the repeatable operator loop.
-2. Strip private inputs and outputs.
-3. Rewrite local paths as repo-relative examples.
-4. Turn one-off instructions into a `When To Use` section and a short process.
-5. Add concrete output requirements.
-6. Run a secret and local-path scan before opening a PR.
-
-## Example: Launch Handoff
-
-Local Hermes prompt:
-
-```text
-Read my local workspace files and finalize launch copy.
-```
-
-ECC-safe version:
-
-```text
-Use the public release pack under docs/releases/<version>/.
-Return one X thread, one LinkedIn post, one recording checklist, and the missing assets list.
-```
-
-## Example: Quiet-Hours Operator Job
-
-Local Hermes job:
-
-```text
-Run my private inbox, finance, and content checks overnight.
-```
-
-ECC-safe version:
-
-```text
-Describe the scheduler policy, the quiet-hours window, the escalation rules, and the categories of checks. Do not include private data sources or credentials.
-```
-
-## Output Contract
-
-Return:
-
-- candidate ECC skill name
-- sanitized workflow summary
-- required public inputs
-- private inputs removed
-- remaining risks
-- files that should be created or updated
+---
+name: hermes-imports
+description: Convert local Hermes operator workflows into sanitized ECC skills and release-pack artifacts. Use when preparing a Hermes workflow for public ECC reuse without leaking private workspace state, credentials, or local-only paths.
+origin: ECC
+---
+
+# Hermes Imports
+
+Use this skill when turning a repeated Hermes workflow into something safe to ship in ECC.
+
+Hermes is the operator shell. ECC is the reusable workflow layer. Imports should move stable patterns from Hermes into ECC without moving private state.
+
+## When To Use
+
+- A Hermes workflow has repeated enough times to become reusable.
+- A local operator prompt should become a public ECC skill.
+- A launch, content, research, or engineering workflow needs sanitized handoff docs.
+- A workflow mentions local paths, credentials, personal datasets, or private account names that must be removed before publication.
+
+## Import Rules
+
+- Convert local paths to repo-relative paths or placeholders.
+- Replace live account names with role labels such as `operator`, `default profile`, or `workspace owner`.
+- Describe credential requirements by provider name only.
+- Keep examples narrow and operational.
+- Do not ship raw workspace exports, tokens, OAuth files, health data, CRM data, or finance data.
+- If the workflow requires private state to make sense, keep it local.
+
+## Sanitization Checklist
+
+Before committing an imported workflow, scan for:
+
+- absolute paths such as `/Users/...`
+- `~/.hermes` paths unless the doc is explicitly explaining local setup
+- API keys, tokens, cookies, OAuth files, or bearer strings
+- phone numbers, private email addresses, and personal contact graphs
+- client names, family names, or account names that are not already public
+- revenue, health, or CRM details
+- raw logs that include tool output from private systems
+
+## Conversion Pattern
+
+1. Identify the repeatable operator loop.
+2. Strip private inputs and outputs.
+3. Rewrite local paths as repo-relative examples.
+4. Turn one-off instructions into a `When To Use` section and a short process.
+5. Add concrete output requirements.
+6. Run a secret and local-path scan before opening a PR.
+
+## Example: Launch Handoff
+
+Local Hermes prompt:
+
+```text
+Read my local workspace files and finalize launch copy.
+```
+
+ECC-safe version:
+
+```text
+Use the public release pack under docs/releases/<version>/.
+Return one X thread, one LinkedIn post, one recording checklist, and the missing assets list.
+```
+
+## Example: Quiet-Hours Operator Job
+
+Local Hermes job:
+
+```text
+Run my private inbox, finance, and content checks overnight.
+```
+
+ECC-safe version:
+
+```text
+Describe the scheduler policy, the quiet-hours window, the escalation rules, and the categories of checks. Do not include private data sources or credentials.
+```
+
+## Output Contract
+
+Return:
+
+- candidate ECC skill name
+- sanitized workflow summary
+- required public inputs
+- private inputs removed
+- remaining risks
+- files that should be created or updated