@funnycode/myclaude 0.1.70 → 0.1.71

package/seed/marketplaces/ecc/skills/hipaa-compliance/SKILL.md

@@ -1,78 +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`
+---
+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`

package/seed/marketplaces/ecc/skills/homelab-network-readiness/SKILL.md

@@ -1,169 +1,169 @@
----
-name: homelab-network-readiness
-description: Readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.
-origin: community
----
-
-# Homelab Network Readiness
-
-Use this skill before changing a home or small-lab network that mixes VLANs,
-Pi-hole or another local DNS resolver, firewall rules, and remote VPN access.
-
-This is a planning and review skill. Do not turn it into copy-paste router,
-firewall, or VPN configuration unless the target platform, current topology,
-rollback path, console access, and maintenance window are all known.
-
-## When to Use
-
-- Preparing to split a flat network into trusted, IoT, guest, server, or
-  management VLANs.
-- Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS
-  resolver.
-- Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access.
-- Reviewing whether a homelab change can lock the operator out of the gateway,
-  switch, access point, DNS server, or VPN server.
-- Turning an informal home-network idea into a staged migration plan with
-  validation evidence.
-
-## Safety Rules
-
-- Keep the first answer read-only: inventory, risks, staged plan, validation,
-  and rollback.
-- Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN
-  management UIs directly to the public internet.
-- Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed
-  platform and a rollback procedure.
-- Require out-of-band or same-room console access before changing management
-  VLANs, trunk ports, firewall default policies, or DHCP/DNS settings.
-- Keep a working path back to the internet before pointing the whole network at
-  a new DNS resolver or VPN route.
-- Treat IoT, guest, camera, and lab-server networks as different trust zones
-  until the operator explicitly chooses otherwise.
-
-## Required Inventory
-
-Collect this before giving implementation steps:
-
-| Area | Questions |
-| --- | --- |
-| Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? |
-| Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? |
-| Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? |
-| Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? |
-| Addressing | What subnets exist today, and which ranges conflict with VPN sites? |
-| DNS/DHCP | Which service currently hands out leases and resolver addresses? |
-| Management | How will the operator reach the gateway, switch, and AP after changes? |
-| Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? |
-
-## VLAN And Trust-Zone Plan
-
-Start with intent rather than vendor syntax.
-
-| Zone | Typical contents | Default policy |
-| --- | --- | --- |
-| Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed |
-| Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients |
-| IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only |
-| Guest | Visitor devices | Internet-only, no LAN reachability |
-| Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices |
-| VPN | Remote clients | Same or narrower access than trusted clients |
-
-Before recommending VLAN IDs or subnets, confirm:
-
-1. The gateway supports inter-VLAN routing and firewall rules.
-2. The switch supports the required tagged and untagged port behavior.
-3. The APs can map SSIDs to VLANs.
-4. The operator knows which port they are connected through during the change.
-5. The management network remains reachable after trunk and SSID changes.
-
-## DNS Filtering Readiness
-
-Pi-hole or another local resolver should be introduced as a dependency, not as a
-single point of failure.
-
-1. Give the resolver a reserved address before using it in DHCP options.
-2. Confirm it can resolve public DNS and local `home.arpa` names.
-3. Keep the gateway or a second resolver available as a temporary fallback.
-4. Test one client or one VLAN before changing every DHCP scope.
-5. Document which networks may bypass filtering and why.
-6. Check that blocking rules do not break captive portals, work VPNs, firmware
-   updates, or medical/security devices.
-
-Useful validation evidence:
-
-```text
-Client gets expected DHCP lease
-Client receives expected DNS resolver
-Public DNS lookup succeeds
-Local home.arpa lookup succeeds
-Blocked test domain is blocked only where intended
-Gateway and DNS admin interfaces are not reachable from guest or IoT networks
-```
-
-## Remote Access Readiness
-
-For WireGuard-style access, decide what the VPN is allowed to reach before
-generating keys or opening ports.
-
-| Mode | Use when | Risk notes |
-| --- | --- | --- |
-| Split tunnel to one subnet | Remote admin for NAS or lab hosts | Keep route list narrow |
-| Split tunnel to trusted services | Access selected apps by IP or DNS | Requires precise firewall rules |
-| Full tunnel | Untrusted networks or travel | More bandwidth and DNS responsibility |
-| Overlay VPN | Simpler remote access with identity controls | Still needs ACL review |
-
-Do not recommend port forwarding until the operator confirms:
-
-- The VPN endpoint is patched and actively maintained.
-- The forwarded port goes only to the VPN service, not an admin UI.
-- Dynamic DNS, public IP behavior, and ISP CGNAT status are understood.
-- Peer keys can be revoked without rebuilding the whole network.
-- Logs or connection status can verify who connected and when.
-
-## Change Sequence
-
-Prefer small, reversible changes:
-
-1. Snapshot the current topology, IP plan, DHCP settings, DNS settings, and
-   firewall rules.
-2. Reserve infrastructure addresses for gateway, DNS, controller, APs, NAS, and
-   VPN endpoint.
-3. Create the new zone or VLAN without moving critical devices.
-4. Move one test client and validate DHCP, DNS, routing, internet, and block
-   behavior.
-5. Add narrow firewall exceptions for required flows.
-6. Move one low-risk device group.
-7. Add VPN access with the narrowest route and firewall policy that satisfies
-   the use case.
-8. Document final state, known exceptions, and rollback commands or UI steps.
-
-## Review Checklist
-
-- Each network has a reason to exist and a clear trust boundary.
-- No management interface is reachable from guest, IoT, or the public internet.
-- DNS failure does not take down the operator's ability to recover locally.
-- DHCP scope changes were tested on one client before broad rollout.
-- VPN clients receive only the routes and DNS settings they need.
-- Firewall rules are default-deny between zones, with named exceptions.
-- The operator can still reach gateway, switch, AP, DNS, and VPN admin surfaces.
-- Rollback is documented in the same vocabulary as the chosen platform UI or
-  CLI.
-
-## Anti-Patterns
-
-- Segmenting networks before knowing which switch ports and SSIDs carry which
-  VLANs.
-- Moving the admin workstation off the only reachable management network.
-- Pointing all DHCP scopes at a Pi-hole before testing fallback DNS.
-- Publishing NAS, DNS, router, or hypervisor management directly to the
-  internet.
-- Treating VPN access as equivalent to full trusted-LAN access.
-- Adding allow-all firewall rules temporarily and forgetting to remove them.
-- Copying commands from another vendor or firmware version without checking the
-  exact platform syntax.
-
-## See Also
-
-- Skill: `homelab-network-setup`
-- Skill: `network-config-validation`
-- Skill: `network-interface-health`
+---
+name: homelab-network-readiness
+description: Readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.
+origin: community
+---
+
+# Homelab Network Readiness
+
+Use this skill before changing a home or small-lab network that mixes VLANs,
+Pi-hole or another local DNS resolver, firewall rules, and remote VPN access.
+
+This is a planning and review skill. Do not turn it into copy-paste router,
+firewall, or VPN configuration unless the target platform, current topology,
+rollback path, console access, and maintenance window are all known.
+
+## When to Use
+
+- Preparing to split a flat network into trusted, IoT, guest, server, or
+  management VLANs.
+- Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS
+  resolver.
+- Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access.
+- Reviewing whether a homelab change can lock the operator out of the gateway,
+  switch, access point, DNS server, or VPN server.
+- Turning an informal home-network idea into a staged migration plan with
+  validation evidence.
+
+## Safety Rules
+
+- Keep the first answer read-only: inventory, risks, staged plan, validation,
+  and rollback.
+- Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN
+  management UIs directly to the public internet.
+- Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed
+  platform and a rollback procedure.
+- Require out-of-band or same-room console access before changing management
+  VLANs, trunk ports, firewall default policies, or DHCP/DNS settings.
+- Keep a working path back to the internet before pointing the whole network at
+  a new DNS resolver or VPN route.
+- Treat IoT, guest, camera, and lab-server networks as different trust zones
+  until the operator explicitly chooses otherwise.
+
+## Required Inventory
+
+Collect this before giving implementation steps:
+
+| Area | Questions |
+| --- | --- |
+| Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? |
+| Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? |
+| Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? |
+| Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? |
+| Addressing | What subnets exist today, and which ranges conflict with VPN sites? |
+| DNS/DHCP | Which service currently hands out leases and resolver addresses? |
+| Management | How will the operator reach the gateway, switch, and AP after changes? |
+| Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? |
+
+## VLAN And Trust-Zone Plan
+
+Start with intent rather than vendor syntax.
+
+| Zone | Typical contents | Default policy |
+| --- | --- | --- |
+| Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed |
+| Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients |
+| IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only |
+| Guest | Visitor devices | Internet-only, no LAN reachability |
+| Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices |
+| VPN | Remote clients | Same or narrower access than trusted clients |
+
+Before recommending VLAN IDs or subnets, confirm:
+
+1. The gateway supports inter-VLAN routing and firewall rules.
+2. The switch supports the required tagged and untagged port behavior.
+3. The APs can map SSIDs to VLANs.
+4. The operator knows which port they are connected through during the change.
+5. The management network remains reachable after trunk and SSID changes.
+
+## DNS Filtering Readiness
+
+Pi-hole or another local resolver should be introduced as a dependency, not as a
+single point of failure.
+
+1. Give the resolver a reserved address before using it in DHCP options.
+2. Confirm it can resolve public DNS and local `home.arpa` names.
+3. Keep the gateway or a second resolver available as a temporary fallback.
+4. Test one client or one VLAN before changing every DHCP scope.
+5. Document which networks may bypass filtering and why.
+6. Check that blocking rules do not break captive portals, work VPNs, firmware
+   updates, or medical/security devices.
+
+Useful validation evidence:
+
+```text
+Client gets expected DHCP lease
+Client receives expected DNS resolver
+Public DNS lookup succeeds
+Local home.arpa lookup succeeds
+Blocked test domain is blocked only where intended
+Gateway and DNS admin interfaces are not reachable from guest or IoT networks
+```
+
+## Remote Access Readiness
+
+For WireGuard-style access, decide what the VPN is allowed to reach before
+generating keys or opening ports.
+
+| Mode | Use when | Risk notes |
+| --- | --- | --- |
+| Split tunnel to one subnet | Remote admin for NAS or lab hosts | Keep route list narrow |
+| Split tunnel to trusted services | Access selected apps by IP or DNS | Requires precise firewall rules |
+| Full tunnel | Untrusted networks or travel | More bandwidth and DNS responsibility |
+| Overlay VPN | Simpler remote access with identity controls | Still needs ACL review |
+
+Do not recommend port forwarding until the operator confirms:
+
+- The VPN endpoint is patched and actively maintained.
+- The forwarded port goes only to the VPN service, not an admin UI.
+- Dynamic DNS, public IP behavior, and ISP CGNAT status are understood.
+- Peer keys can be revoked without rebuilding the whole network.
+- Logs or connection status can verify who connected and when.
+
+## Change Sequence
+
+Prefer small, reversible changes:
+
+1. Snapshot the current topology, IP plan, DHCP settings, DNS settings, and
+   firewall rules.
+2. Reserve infrastructure addresses for gateway, DNS, controller, APs, NAS, and
+   VPN endpoint.
+3. Create the new zone or VLAN without moving critical devices.
+4. Move one test client and validate DHCP, DNS, routing, internet, and block
+   behavior.
+5. Add narrow firewall exceptions for required flows.
+6. Move one low-risk device group.
+7. Add VPN access with the narrowest route and firewall policy that satisfies
+   the use case.
+8. Document final state, known exceptions, and rollback commands or UI steps.
+
+## Review Checklist
+
+- Each network has a reason to exist and a clear trust boundary.
+- No management interface is reachable from guest, IoT, or the public internet.
+- DNS failure does not take down the operator's ability to recover locally.
+- DHCP scope changes were tested on one client before broad rollout.
+- VPN clients receive only the routes and DNS settings they need.
+- Firewall rules are default-deny between zones, with named exceptions.
+- The operator can still reach gateway, switch, AP, DNS, and VPN admin surfaces.
+- Rollback is documented in the same vocabulary as the chosen platform UI or
+  CLI.
+
+## Anti-Patterns
+
+- Segmenting networks before knowing which switch ports and SSIDs carry which
+  VLANs.
+- Moving the admin workstation off the only reachable management network.
+- Pointing all DHCP scopes at a Pi-hole before testing fallback DNS.
+- Publishing NAS, DNS, router, or hypervisor management directly to the
+  internet.
+- Treating VPN access as equivalent to full trusted-LAN access.
+- Adding allow-all firewall rules temporarily and forgetting to remove them.
+- Copying commands from another vendor or firmware version without checking the
+  exact platform syntax.
+
+## See Also
+
+- Skill: `homelab-network-setup`
+- Skill: `network-config-validation`
+- Skill: `network-interface-health`