rsc-universal 0.1.1

package/skills/gcp-essentials/scripts/verify.sh

@@ -0,0 +1,158 @@
+#!/usr/bin/env bash
+# verify.sh — offline static linter for GCP gcloud command blocks.
+#
+# Flags known-unsafe patterns in files that contain `gcloud` commands:
+#   - service-account JSON key creation
+#   - roles/owner or roles/editor bound to a serviceAccount member
+#   - bucket create missing --uniform-bucket-level-access or --public-access-prevention
+#   - Cloud SQL create using public IP (--assign-ip / no --no-assign-ip)
+#   - Cloud Run deploy/replace missing --service-account
+#
+# No network, no gcloud, read-only. Prints PASS/FAIL per check.
+# Exit 0 when the target is empty/clean, nonzero when any FAIL is found.
+#
+# Usage:
+#   bash verify.sh <file-or-dir> [<file-or-dir> ...]
+#   bash verify.sh                # defaults to the skill dir (SKILL.md + references/)
+
+set -uo pipefail
+
+# ---- collect target files -------------------------------------------------
+declare -a TARGETS=()
+if [[ $# -eq 0 ]]; then
+  here="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+  TARGETS=("$here")
+else
+  TARGETS=("$@")
+fi
+
+declare -a FILES=()
+for t in "${TARGETS[@]}"; do
+  if [[ -d "$t" ]]; then
+    while IFS= read -r f; do FILES+=("$f"); done < <(
+      find "$t" -type f \( -name '*.sh' -o -name '*.md' -o -name '*.bash' -o -name '*.txt' \) 2>/dev/null
+    )
+  elif [[ -f "$t" ]]; then
+    FILES+=("$t")
+  else
+    echo "WARN  no such file or directory: $t" >&2
+  fi
+done
+
+if [[ ${#FILES[@]} -eq 0 ]]; then
+  echo "PASS  no target files to lint (clean)"
+  exit 0
+fi
+
+fails=0
+
+# report FAIL <check> <file> <lineno> <line>
+report() {
+  printf 'FAIL  %-22s %s:%s: %s\n' "$1" "$2" "$3" "$4"
+  fails=$((fails + 1))
+}
+
+for f in "${FILES[@]}"; do
+  lineno=0
+  # Track context for multi-line `gcloud` commands joined by trailing backslash.
+  buf=""
+  buf_start=0
+  flush_buf() {
+    [[ -z "$buf" ]] && return
+    local cmd="$buf"
+    # --- Cloud Run deploy/replace must carry --service-account ---
+    if echo "$cmd" | grep -Eq 'gcloud[[:space:]]+run[[:space:]]+(deploy|services[[:space:]]+replace)'; then
+      if ! echo "$cmd" | grep -q -- '--service-account'; then
+        report "run-no-service-account" "$f" "$buf_start" "gcloud run deploy/replace without --service-account"
+      fi
+    fi
+    # --- bucket create must carry UBLA and PAP ---
+    if echo "$cmd" | grep -Eq 'gcloud[[:space:]]+storage[[:space:]]+buckets[[:space:]]+create'; then
+      if ! echo "$cmd" | grep -q -- '--uniform-bucket-level-access'; then
+        report "bucket-no-ubla" "$f" "$buf_start" "bucket create missing --uniform-bucket-level-access"
+      fi
+      if ! echo "$cmd" | grep -q -- '--public-access-prevention'; then
+        report "bucket-no-pap" "$f" "$buf_start" "bucket create missing --public-access-prevention"
+      fi
+    fi
+    # --- Cloud SQL create must not use public IP ---
+    if echo "$cmd" | grep -Eq 'gcloud[[:space:]]+sql[[:space:]]+instances[[:space:]]+create'; then
+      if echo "$cmd" | grep -Eq -- '--assign-ip([^a-z]|$)'; then
+        report "sql-public-ip" "$f" "$buf_start" "Cloud SQL create uses --assign-ip (public IP)"
+      elif ! echo "$cmd" | grep -q -- '--no-assign-ip'; then
+        report "sql-no-private" "$f" "$buf_start" "Cloud SQL create missing --no-assign-ip (defaults to public IP)"
+      fi
+    fi
+    buf=""
+  }
+
+  # For Markdown files, only lint inside fenced code blocks (```bash / ```sh /
+  # ```). Prose and anti-pattern table cells (which quote unsafe commands on
+  # purpose) must not trip the linter. Non-.md files are treated as all-code.
+  in_code=true
+  is_md=false
+  case "$f" in
+    *.md) is_md=true; in_code=false ;;
+  esac
+
+  while IFS= read -r line || [[ -n "$line" ]]; do
+    lineno=$((lineno + 1))
+
+    # Toggle fenced-code state for Markdown.
+    if $is_md && [[ "$line" =~ ^[[:space:]]*\`\`\` ]]; then
+      if $in_code; then in_code=false; else in_code=true; fi
+      flush_buf
+      continue
+    fi
+    if ! $in_code; then
+      continue
+    fi
+
+    # Skip prose/comment-only lines for keyword checks but still scan for the
+    # hard banned single-line patterns below.
+    stripped="${line#"${line%%[![:space:]]*}"}"   # ltrim
+    is_comment=false
+    [[ "$stripped" == \#* ]] && is_comment=true
+
+    # ---- single-line hard bans (checked on every non-comment line) ----
+    if ! $is_comment; then
+      # JSON key creation — never.
+      if echo "$line" | grep -Eq 'gcloud[[:space:]]+iam[[:space:]]+service-accounts[[:space:]]+keys[[:space:]]+create'; then
+        report "sa-json-key-create" "$f" "$lineno" "$stripped"
+      fi
+      # primitive owner/editor bound to a service account.
+      if echo "$line" | grep -Eq -- '--role=("?)roles/(owner|editor)\b' \
+         && echo "$line" | grep -q 'serviceAccount:'; then
+        report "primitive-role-on-sa" "$f" "$lineno" "$stripped"
+      fi
+      # primitive owner/editor in a member+role grant spanning the same command
+      # (covers the common case where role is on the same line).
+    fi
+
+    # ---- accumulate multi-line gcloud commands (backslash continuation) ----
+    if $is_comment; then
+      flush_buf
+      continue
+    fi
+    if [[ -n "$buf" ]]; then
+      buf="$buf $stripped"
+    elif echo "$stripped" | grep -Eq '^gcloud([[:space:]]|$)'; then
+      buf="$stripped"
+      buf_start=$lineno
+    fi
+    # End of a command when the line does not end in a backslash.
+    if [[ -n "$buf" && "${line%\\}" == "$line" ]]; then
+      flush_buf
+    fi
+  done < "$f"
+  flush_buf
+done
+
+echo "----"
+if [[ $fails -eq 0 ]]; then
+  echo "PASS  ${#FILES[@]} file(s) linted, no unsafe gcloud patterns found"
+  exit 0
+else
+  echo "FAIL  $fails unsafe pattern(s) found across ${#FILES[@]} file(s)"
+  exit 1
+fi

package/skills/gdpr-privacy/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: gdpr-privacy
+description: "Use when getting a product or website into practical GDPR shape: a privacy policy that matches what the product actually does, a cookie/consent banner, a defensible lawful basis per processing activity, a Record of Processing Activities, an Article 28 data-processing agreement with a vendor, an international-transfer mechanism (SCCs), or a working data-subject-rights flow. Triggers: 'write a GDPR privacy policy', 'is our cookie banner compliant', 'consent or legitimate interest for product emails', 'write the LIA', 'review this vendor DPA', 'we send data to a US sub-processor what mechanism', 'build our ROPA', 'how do we handle a DSAR / right to erasure', 'do we need a DPIA', 'redacta nuestra política de privacidad RGPD', 'revisa el banner de cookies perquè el rebuig sigui tan fàcil com acceptar'. NOT internal data retention/classification rules (that is data-policy) and NOT the consumer Terms of Service contract (that is terms-conditions)."
+tags: [gdpr, privacy, data-protection, cookies, consent, lawful-basis, dpa, scc, dsar, ropa, dpia, rgpd]
+recommends: [data-policy, terms-conditions, contracts, compliance, secure-coding, email-deliverability]
+origin: risco
+---
+
+# GDPR privacy
+
+You produce the GDPR artifacts a product must publish or hand to data subjects, vendors, and regulators: privacy policy, cookie/consent banner, lawful-basis record, ROPA, the Article 28 DPA, transfer mechanism, and the data-subject-rights flow. You are not a lawyer and you never say you are.
+
+Three standing rules. Hold them through every task.
+
+1. **Every artifact maps to a real processing activity.** Never describe data the product does not process. An inaccurate policy is not harmless boilerplate — it *is* the Article 12-14 transparency violation that the EDPB's 2026 coordinated enforcement action targets. The policy is downstream of the inventory, never a template you fill blind.
+2. **Name the lawful basis and its *why* for each purpose.** Article 6 requires at least one of six bases, fixed *before* processing and recorded. "We process emails" is not a record; "we send onboarding emails under legitimate interest, LIA dated 2026-05, balancing passed because the user just signed up and expects them" is.
+3. **Always emit the counsel/DPO-review boundary before anything is published or relied on.** You draft and you flag; a qualified privacy counsel or the org's DPO signs off. Say so every time.
+
+Current law is the 2016 GDPR (Regulation 2016/679). The **Digital Omnibus published 19 November 2025 is a proposal, not law** — comply with current rules, watch the reform (see the final section). Do not draft to proposed rules as if enacted.
+
+## First move: inventory before you draft
+
+You cannot write a truthful policy without knowing the processing. Before any artifact, get the inventory — this is the Article 30 ROPA, and it is the source of truth that feeds everything else:
+
+- **What** personal data (categories: contact, usage/analytics, payment, special categories under Art. 9)?
+- **Why** — the purpose, stated per use, not "to run the service"?
+- **From whom**, and is it collected from the person (Art. 13) or obtained elsewhere (Art. 14)?
+- **Retained** how long, and on what trigger does it get deleted?
+- **Shared with** which recipients and sub-processors?
+- **Transferred** where — does any of it leave the EEA?
+
+If you don't have these answers, ask for them or state the assumption explicitly in the draft. Do not invent processing to fill a template.
+
+Then route the request to the artifact it actually needs:
+
+| The request | Artifact you produce | Load-bearing rule | Reference |
+|---|---|---|---|
+| "Write a privacy policy" | Art. 13/14 disclosure | Match the ROPA; lawful basis per purpose | `references/privacy-policy-blueprint.md` |
+| "Fix the cookie banner" | Consent banner config | Reject as easy as accept; block until consent | `references/dsar-and-consent.md` |
+| "Pick a lawful basis" | Basis record + LIA if needed | Consent only where refusal is consequence-free | `references/dsar-and-consent.md` |
+| "Review/draft a DPA" | Art. 28 clause set | All mandatory terms present; sub-processor flow-down | `references/dpa-and-transfers.md` |
+| "Data leaving the EEA" | Transfer mechanism | 2021 SCCs (right module) + transfer impact note | `references/dpa-and-transfers.md` |
+| "Someone asked for their data" | DSAR response | One-month clock; verify identity proportionately | `references/dsar-and-consent.md` |
+| "New high-risk feature" | DPIA | Mandatory before high-risk processing starts | this file, §ROPA/DPIA/breach |
+
+## Lawful basis (Article 6)
+
+Six bases, pick at least one per purpose, record it before processing: **consent**, **contract** (necessary to perform a contract with the person), **legal obligation**, **vital interests**, **public task**, **legitimate interests**. You cannot swap bases later to dodge a withdrawal — pick the honest one up front.
+
+The pivotal call is **consent vs legitimate interest**:
+
+- **Consent** (Art. 4(11) + Recital 32): freely given, specific, informed, unambiguous, and *as easy to withdraw as to give*. Use it only where the person has a genuine, consequence-free ability to refuse. You cannot use consent for something the person can't actually decline (e.g. processing necessary for the employment relationship — use contract or legal obligation there).
+- **Legitimate interest** (Art. 6(1)(f)): requires a written, dated three-part **Legitimate Interests Assessment (LIA)** — purpose, necessity, balancing — kept on file. No LIA, no legitimate-interest basis.
+
+```text
+Bad:  "We rely on consent for analytics." — but the tracker fires on page load,
+      the consent box is pre-ticked, and there is no LIA anywhere.
+      => invalid consent (pre-ticked, not affirmative) AND no fallback basis.
+
+Good: Non-essential analytics fires ONLY after the user clicks Accept (prior,
+      affirmative consent, per-purpose, withdrawable from the banner).
+      Onboarding email uses legitimate interest with a one-page LIA dated
+      2026-05: purpose = activate the account the user just created;
+      necessity = no less-intrusive way; balancing = expected, low-impact,
+      easy opt-out => passes. Marketing email uses consent (separate opt-in).
+```
+
+LIA template lives in `references/dsar-and-consent.md`.
+
+## Cookies & consent
+
+- **Reject must be as easy as accept.** Surface Accept-all and Reject-all at the same level, same friction, same prominence. A banner where Accept is one click and Reject is buried two layers down is non-compliant. CNIL fined Google €325M and Shein €150M in September 2025 over exactly this; the EDPB Cookie Banner Task Force position is settled.
+- **Block non-essential cookies/trackers until affirmative consent.** A banner that sets analytics or ad trackers on page load is non-compliant *regardless of the copy* — the timing is the violation, not the wording.
+- **Consent is per-purpose and withdrawable.** No bundling "analytics + ads + personalization" into one toggle; withdrawing must be as easy as giving.
+- **The rule is the ePrivacy *Directive* (2002/58/EC), transposed per member state.** The ePrivacy *Regulation* was formally withdrawn by the Commission in February 2025 — there is no single EU-wide cookie rule. Banner rules vary by country; flag that variance, don't assume one config covers all of the EEA.
+
+Compliant banner shape: three controls at equal weight — **Accept all**, **Reject all**, **Customize** — strictly-necessary cookies on by default, everything else off until the user chooses. Config shape in `references/dsar-and-consent.md`.
+
+## The privacy policy (Articles 13/14)
+
+Write it to match the ROPA, in plain language, with no catch-all lies ("we may collect any and all data" is itself a violation). Mandatory disclosures:
+
+- Identity and contact details of the controller (and EU representative if applicable).
+- DPO contact, if you have one.
+- The purposes **and the lawful basis per purpose** — and where the basis is legitimate interest, state the interest.
+- Recipients or categories of recipients (including sub-processors).
+- International transfers and the mechanism relied on (SCCs / DPF / adequacy).
+- Retention period per category, or the criteria used to set it.
+- The full data-subject-rights list, *how* to exercise each, and the right to lodge a complaint with a supervisory authority.
+- Whether there is automated decision-making / profiling, with meaningful info about the logic.
+- Source of the data, if not collected from the person (Art. 14 case).
+
+Fill-in blueprint with a "why required" per section: `references/privacy-policy-blueprint.md`.
+
+## DPAs & transfers
+
+**Article 28 requires a binding written DPA whenever a processor handles personal data on your behalf** (or, when you're the processor, that a controller demand one from you). Mandatory clauses — check every one is present, demand them as controller, offer them as processor:
+
+- Process only on the controller's documented instructions.
+- Confidentiality commitment from anyone handling the data.
+- Article 32 security measures (technical and organizational).
+- Sub-processor authorization plus flow-down of the same obligations, and a change-notice right.
+- Assist the controller with data-subject rights and with breach notification.
+- Delete or return the data at the end of the engagement.
+- Submit to and contribute to audits.
+
+**Transfers outside the EEA need a valid mechanism.** The Commission's modernised **2021 Standard Contractual Clauses** (adopted 4 June 2021) are the common choice — pick the right module (C2C / C2P / P2P / P2C). The 2021 SCCs already incorporate Art. 28 terms, so the transfer doesn't need a separate DPA on top. Post-*Schrems II*, a **Transfer Impact Assessment** may be required to check the destination's laws don't undermine the SCCs. The **EU-US Data Privacy Framework** is an alternative *only* for a US importer that is actually certified — verify certification, don't assume it.
+
+Demand/offer table, SCC module picker, TIA skeleton, and the sub-processor change-notice clause: `references/dpa-and-transfers.md`.
+
+## Data-subject rights flow
+
+The clock is **one month from receipt** to respond (access Art. 15, erasure Art. 17, portability, rectification, objection, restriction). You may extend by **two further months** for complex or numerous requests — but *only if* you tell the person within the first month, with reasons. Silent extension is a breach.
+
+The flow:
+
+1. **Log receipt** with the date — that starts the clock.
+2. **Verify identity proportionately.** Confirm who they are, but don't over-collect to do it (don't demand a passport scan to release an email address you already hold).
+3. **Route by right:** access (give a copy + the Art. 15 context), erasure, portability (machine-readable, commonly used format), rectification, objection, restriction.
+4. **Apply exceptions.** Erasure is *not* absolute — legal-obligation retention, freedom of expression, and establishment/exercise of legal claims are carve-outs. Note which applies and why.
+5. **Respond free of charge** unless the request is manifestly unfounded or excessive (then you may charge a reasonable fee or refuse, with reasons).
+
+Per-right runbook: `references/dsar-and-consent.md`.
+
+## ROPA + DPIA + breach (the documentation trio)
+
+- **ROPA (Art. 30):** maintain it; the supervisory authority can demand it on request. It is the spine that feeds the policy, the DPA, and the transfer record. If the org has no ROPA, building one is the first deliverable.
+- **DPIA (Art. 35):** mandatory *before* any processing "likely to result in a high risk." Trigger checklist — do a DPIA if any apply: large-scale processing of special categories (Art. 9 data), systematic monitoring of a public area, or novel/high-risk technology (e.g. new biometric or AI-driven profiling). When in doubt, do it.
+- **Breach (Art. 33/34):** notify the supervisory authority **within 72 hours** of becoming aware, unless the breach is unlikely to result in risk; notify affected individuals when the risk to them is high. Have the contact and the template ready *before* a breach, not during.
+
+## The legal boundary (non-negotiable)
+
+This skill drafts artifacts and flags issues. It is **not legal advice**. Emit the counsel/DPO-review line before anything is published or relied on — every time, no exceptions.
+
+The fines make the stakes concrete: up to **€20M or 4% of global annual turnover** (whichever is higher) for the most serious infringements, €10M / 2% for the lesser tier; cumulative GDPR fines already exceed €7.1B. This is not a Big-Tech-only risk.
+
+Hand off what isn't yours:
+
+- Internal data retention, classification, governance posture → `../data-policy/SKILL.md`.
+- The user-facing Terms of Service / EULA → `../terms-conditions/SKILL.md`.
+- The commercial paper around a DPA (liability, indemnity, the MSA) → `../contracts/SKILL.md`.
+- SOC 2 / ISO 27001 / audit-evidence posture → `../compliance/SKILL.md`.
+- The Article 32 code-level controls (encryption, authz, secrets) → `../secure-coding/SKILL.md`.
+- Email opt-in mechanics / SPF / DKIM / list hygiene → `../email-deliverability/SKILL.md` (the *consent* substance stays here).
+
+## Anti-patterns
+
+| Anti-pattern | Fix |
+|---|---|
+| Drafts a policy describing data the product doesn't process (boilerplate-lie) | Write from the ROPA; if you don't have it, get it or state the assumption |
+| Cookie banner: Accept one click, Reject buried two layers down | Equal-weight Accept-all / Reject-all at the same level |
+| Sets trackers on page load behind the banner | Block non-essential cookies until affirmative consent — timing is the violation |
+| Uses consent for something the person can't refuse (e.g. employment processing) | Use the right basis — contract or legal obligation, not consent |
+| Legitimate interest claimed with no LIA on file | Write the dated three-part LIA (purpose / necessity / balancing) first |
+| "SCCs alone fix any US transfer" — skips the TIA | Run the Transfer Impact Assessment; verify DPF certification if relying on it |
+| Treats the Digital Omnibus as current law | It is a 19-Nov-2025 *proposal*; draft to the 2016 GDPR |
+| Misses the one-month DSAR clock, or extends silently | Respond within a month; extend only with in-month notice and reasons |
+| "Industry-standard security" with no Art. 32 reference | Cite Article 32 and describe the actual measures |
+| Says it's giving legal advice / the policy is safe to publish unreviewed | Flag for qualified privacy counsel / DPO every time |
+
+## References
+
+- `references/privacy-policy-blueprint.md` — Art. 13/14 mandatory-disclosure sections as `[BRACKET]` fill-ins, each with a "why required" line.
+- `references/dpa-and-transfers.md` — Art. 28 demand/offer clause table, 2021 SCC module picker, TIA skeleton, DPF note, sub-processor change-notice clause.
+- `references/dsar-and-consent.md` — data-subject-rights runbook, the LIA three-part template, a compliant cookie-banner config shape, and the `verify.sh` banlist rationale.
+
+Run `scripts/verify.sh <artifact-file>` over any policy/banner/DPA you emit to catch missing Art. 13/14 tokens, placeholder leftovers, boilerplate-lies, and a banner missing its reject control.

package/skills/gdpr-privacy/evals/README.md

@@ -0,0 +1,3 @@
+# Evals: gdpr-privacy
+
+These cases are routing and coverage checks, not an automated pass/fail suite. Read `cases.yaml` against `SKILL.md`. For each `should_trigger` prompt, confirm the description and body would plausibly fire this skill and not a sibling (note the Spanish and Catalan triggers and the non-obvious consent-vs-legitimate-interest and US-transfer cases); for each `should_not_trigger` prompt, confirm the named `route_to` sibling is the better home and that this skill's boundary section would defer to it. For the `capability` case, have a human or a harness LLM produce the response and check it hits every `must_include` item — above all that it starts from a processing inventory, assigns a basis per purpose, fixes reject-parity and block-until-consent on the banner, handles the US transfers with SCCs + a transfer impact note, respects the one-month DSAR clock, and emits the counsel/DPO-review boundary while treating the Digital Omnibus as a proposal. There is no scripted assertion here. The separate `scripts/verify.sh` is the only automated check, and it inspects an emitted artifact (policy / banner / DPA), not these cases.

package/skills/gdpr-privacy/evals/cases.yaml

@@ -0,0 +1,47 @@
+skill: gdpr-privacy
+
+should_trigger:
+  - prompt: "Write a GDPR-compliant privacy policy for our B2B SaaS."
+    why: Core artifact — the Art. 13/14 disclosure written to match the product's processing.
+  - prompt: "Is our cookie banner compliant? Reject is two clicks but accept is one."
+    why: Live enforcement front — reject-as-easy-as-accept (CNIL Google/Shein fines), the exact rule.
+  - prompt: "Should product onboarding emails use consent or legitimate interest? Write the LIA."
+    why: Non-obvious lawful-basis call plus the required three-part Legitimate Interests Assessment.
+  - prompt: "This processor sent their DPA — what should I push back on?"
+    why: Art. 28 review — checking the mandatory processor clauses are present.
+  - prompt: "We're about to send customer data to a US analytics vendor — what transfer mechanism do we need?"
+    why: Non-obvious — SCC module choice + transfer impact assessment for an EEA-out transfer.
+  - prompt: "Someone emailed asking us to delete all their data — what's our deadline and process?"
+    why: DSAR/erasure flow and the one-month statutory clock with exceptions.
+  - prompt: "Redacta nuestra política de privacidad conforme al RGPD."
+    why: Spanish trigger — drafting the privacy policy under GDPR.
+  - prompt: "Revisa el banner de cookies del web perquè el rebuig sigui tan fàcil com acceptar."
+    why: Catalan trigger — cookie-banner review with the reject-parity rule.
+
+should_not_trigger:
+  - prompt: "Define our internal data retention schedule and data-classification tiers."
+    route_to: data-policy
+    why: Inward-facing governance the org sets for itself, not a published GDPR artifact.
+  - prompt: "Write the Terms of Service / user agreement for our app."
+    route_to: terms-conditions
+    why: The contract with the user, not the privacy disclosure.
+  - prompt: "Negotiate the liability cap and indemnity in this vendor's master agreement."
+    route_to: contracts
+    why: The commercial paper around the deal, not the DPA's privacy substance.
+  - prompt: "Get us SOC 2 Type II ready — what controls and audit evidence do we need?"
+    route_to: compliance
+    why: Standards/audit posture, not a GDPR data-subject artifact.
+  - prompt: "Implement field-level encryption and fix the auth on our API."
+    route_to: secure-coding
+    why: Art. 32 code-level controls are engineering, not the privacy disclosure layer.
+
+capability:
+  - scenario: "We run an EU-based SaaS. We just added product-analytics tracking, send onboarding plus marketing emails, and use a US-hosted analytics vendor and a US email provider. We have no privacy policy, a cookie banner with only an 'Accept all' button, and we just got an email asking us to delete an account. Get us compliant — tell us what to fix and produce the artifacts."
+    must_include:
+      - Starts from a processing inventory / ROPA, not a generic template
+      - Assigns a lawful basis per purpose (analytics vs onboarding email vs marketing email) and writes or flags an LIA where legitimate interest is used
+      - Fixes the cookie banner — equal-weight Reject-all, block non-essential cookies until consent, notes per-member-state variance and that it's the ePrivacy Directive (not the withdrawn Regulation)
+      - Identifies the US transfers and prescribes 2021 SCCs (correct module) plus a transfer impact note, or DPF if the importer is certified
+      - Handles the deletion request within the one-month clock with proportionate identity verification and erasure exceptions
+      - Produces an Art. 13/14-complete privacy policy that matches the inventory with no boilerplate-lie
+      - Emits the privacy-counsel / DPO-review boundary and notes the Digital Omnibus is a proposal, not current law

package/skills/gdpr-privacy/references/dpa-and-transfers.md

@@ -0,0 +1,63 @@
+# DPAs & transfers (Article 28 + SCCs)
+
+## Article 28 mandatory clauses — demand/offer table
+
+A binding written DPA is required whenever a processor handles personal data on a controller's behalf. Check each clause is present. As **controller** you demand them; as **processor** you offer them. Missing any of these is a non-compliant DPA.
+
+| Mandatory clause | As controller, demand | As processor, offer |
+|---|---|---|
+| Process only on documented instructions | Processor acts only on your written instructions; flags if an instruction breaches GDPR | Bind yourself to the controller's documented instructions |
+| Confidentiality | Everyone handling the data is under a confidentiality duty | Confirm staff/contractors are bound to confidentiality |
+| Art. 32 security | Specified technical & organizational measures, not "industry-standard" | List the actual measures you maintain |
+| Sub-processor authorization + flow-down | Prior authorization (or general auth + change notice); same obligations flow down | Name current sub-processors; flow the same terms down |
+| Sub-processor change notice | Right to object before a new sub-processor is engaged | Give advance notice + an objection window |
+| Assist with data-subject rights | Processor helps you answer DSARs | Commit to assisting within a stated time |
+| Assist with breach | Processor notifies you without undue delay so you can meet 72h | Commit to a fast internal notification window |
+| Delete or return at end | Choice to delete or return all data on termination | Offer delete-or-return and certify completion |
+| Audits | Right to audit / receive audit evidence | Provide audit reports / allow audits on reasonable notice |
+
+The surrounding commercial paper (liability cap, indemnity, the MSA the DPA hangs off) is `../contracts/SKILL.md`, not this skill.
+
+## 2021 SCC module picker
+
+The Commission's modernised Standard Contractual Clauses (adopted 4 June 2021) come in four modules. Pick by the roles of the **exporter** (in the EEA) and the **importer** (outside it). The 2021 SCCs already incorporate Art. 28 terms, so a separate DPA for the transfer is not needed on top.
+
+| Module | Exporter → Importer | Typical case |
+|---|---|---|
+| **Module 1 (C2C)** | Controller → Controller | EU company shares data with an independent third-party controller abroad |
+| **Module 2 (C2P)** | Controller → Processor | EU company → a non-EEA vendor processing on its behalf (most common SaaS case) |
+| **Module 3 (P2P)** | Processor → Sub-processor | Your non-EEA sub-processor onward-transfers to its own sub-processor |
+| **Module 4 (P2C)** | Processor → Controller | A processor returns/sends data to a controller outside the EEA |
+
+## Transfer Impact Assessment (TIA) skeleton
+
+Post-*Schrems II*, SCCs alone may not be enough — assess whether the destination's laws undermine them.
+
+```text
+1. Transfer mapped: what data, to whom, to which country, under which module.
+2. Local-law assessment: do the importer's country's surveillance/access laws
+   conflict with the SCC guarantees? (e.g. government access powers)
+3. Supplementary measures (if needed): encryption with EEA-held keys,
+   pseudonymisation, contractual transparency commitments.
+4. Conclusion: transfer can proceed / proceed with measures / cannot proceed.
+5. Reviewer + date; revisit on legal change.
+```
+
+## EU-US Data Privacy Framework (DPF) note
+
+For a US importer, the DPF is an alternative to SCCs **only if that specific importer is actively certified** under the framework. Verify the certification (and its scope) on the DPF list before relying on it — do not assume a US vendor is covered. If certification lapses, you fall back to SCCs + TIA.
+
+## Sub-processor change-notice clause (drop-in text)
+
+```text
+The Processor maintains a current list of sub-processors at [URL/LOCATION].
+The Processor shall give the Controller at least [N, e.g. 30] days' prior
+written notice of any intended addition or replacement of a sub-processor.
+The Controller may object on reasonable data-protection grounds within
+[M, e.g. 14] days; absent agreed resolution, the Controller may terminate the
+affected services.
+```
+
+---
+
+**Before signing or relying on any of this:** have a qualified privacy counsel / your DPO review the DPA and the transfer basis. This is a drafting aid, not legal advice.

package/skills/gdpr-privacy/references/dsar-and-consent.md

@@ -0,0 +1,83 @@
+# DSAR runbook, LIA template & consent banner
+
+## Data-subject-rights (DSAR) runbook
+
+**The clock: one month from receipt** (Art. 12(3)). Extendable by **two further months** for complex or numerous requests — *only if* you tell the person within the first month, with reasons. Silent extension is a breach.
+
+1. **Log receipt + date.** The date the request arrives starts the clock — log it the day it lands, not the day you notice it.
+2. **Verify identity proportionately.** Confirm who they are using data you already hold where possible. Do not over-collect to verify (no passport scan to release an email you already have). Over-collection is itself a processing violation.
+3. **Route by right:**
+
+| Right | Article | What you deliver |
+|---|---|---|
+| Access | 15 | A copy of the data + purposes, recipients, retention, source, rights context |
+| Rectification | 16 | Correct inaccurate/incomplete data and tell recipients |
+| Erasure | 17 | Delete, subject to the exceptions below |
+| Restriction | 18 | Stop processing but keep storing, on stated grounds |
+| Portability | 20 | The data the person provided, in a structured, commonly used, machine-readable format |
+| Objection | 21 | Stop processing based on legitimate interest / direct marketing |
+
+4. **Apply erasure exceptions** (Art. 17(3)) — erasure is *not* absolute. Carve-outs: legal-obligation retention (e.g. tax records), establishment/exercise/defence of legal claims, and freedom of expression and information. State which exception applies and why; erase the rest.
+5. **Charge / refuse only for manifestly unfounded or excessive requests** (Art. 12(5)) — then a reasonable fee or refusal, *with reasons* and the right to complain. Default is free of charge.
+
+## Legitimate Interests Assessment (LIA) — three-part template
+
+Required (Art. 6(1)(f)) before relying on legitimate interest. Date it and keep it on file. No LIA, no legitimate-interest basis.
+
+```text
+LIA — [PURPOSE], dated [DATE], owner [NAME]
+
+1. PURPOSE TEST — Is there a legitimate interest?
+   Interest: [STATE THE INTEREST]
+   Whose: [controller's / third party's]
+   Legitimate & specific? [yes/no + why]
+
+2. NECESSITY TEST — Is the processing necessary for it?
+   Could you achieve the purpose a less-intrusive way? [yes/no]
+   If yes, you cannot rely on legitimate interest — minimise or change basis.
+
+3. BALANCING TEST — Do the individual's rights override the interest?
+   Reasonable expectations: would the person expect this? [yes/no]
+   Impact on the individual: [low/medium/high + why]
+   Safeguards (opt-out, minimisation, transparency): [LIST]
+   Conclusion: [interest prevails / does not — change basis or stop]
+```
+
+## Compliant cookie-banner config shape
+
+Three controls at equal weight; non-essential categories off until the user chooses; nothing fires before consent.
+
+```json
+{
+  "blockUntilConsent": true,
+  "controls": [
+    { "id": "accept-all", "label": "Accept all",  "weight": "primary" },
+    { "id": "reject-all", "label": "Reject all",  "weight": "primary" },
+    { "id": "customize",  "label": "Customize",   "weight": "primary" }
+  ],
+  "categories": [
+    { "id": "necessary",   "default": true,  "lockable": true,  "purpose": "strictly necessary" },
+    { "id": "analytics",   "default": false, "purpose": "usage measurement" },
+    { "id": "marketing",   "default": false, "purpose": "advertising" },
+    { "id": "preferences", "default": false, "purpose": "personalization" }
+  ],
+  "withdrawable": true,
+  "note": "ePrivacy Directive transposed per member state — confirm per-country rules"
+}
+```
+
+Key invariants: `reject-all` is present and at the same `weight` as `accept-all`; `blockUntilConsent` is `true`; only `necessary` defaults to `true`; consent is `withdrawable`.
+
+## verify.sh banlist rationale
+
+`scripts/verify.sh <artifact>` is a heuristic completeness/parity check on an emitted artifact, not a judge of legal correctness. It exists because the two most common, mechanical failures are catchable by text:
+
+- **Privacy policy** missing an Art. 13/14 load-bearing token — a lawful basis, a rights mention, a retention mention, the right to complain to a supervisory authority, a contact. These are the precise omissions the 2026 transparency enforcement action targets.
+- **Boilerplate-lie / placeholder leftovers** — unfilled `[BRACKET]`, "any and all data" catch-alls, "industry-standard security" with no Article 32 reference. These signal a blind template, not a ROPA-derived policy.
+- **Cookie banner** with an `accept` control but no `reject`/`decline`/`rebuig`/`rechazar` control — encodes the reject-as-easy-as-accept rule mechanically.
+
+It exits 0 when given no argument (never blocks) and only fails on a real artifact that violates a rule. It does not and cannot replace counsel review.
+
+---
+
+**Before relying on any DSAR decision, LIA, or banner:** have a qualified privacy counsel / your DPO review it. Drafting aid, not legal advice.

package/skills/gdpr-privacy/references/privacy-policy-blueprint.md

@@ -0,0 +1,99 @@
+# Privacy policy blueprint (Articles 13/14)
+
+Fill-in sections for an Art. 13/14-complete privacy policy. Each carries a one-line **why required**. Replace every `[BRACKET]` — leftover brackets are a `verify.sh` failure and a signal the policy is a blind template. Write each section to match the ROPA; never describe data the product does not process.
+
+Order: controller → DPO → purposes + basis → recipients → transfers → retention → rights → complaint → automated decision-making → source.
+
+## 1. Controller identity & contact
+
+```text
+Data controller: [LEGAL ENTITY NAME], [REGISTERED ADDRESS].
+Contact: [EMAIL] / [POSTAL ADDRESS].
+EU representative (if controller is outside the EEA): [NAME / CONTACT, or "not applicable"].
+```
+Why required: Art. 13(1)(a) — the data subject must know who is responsible and how to reach them.
+
+## 2. Data Protection Officer
+
+```text
+DPO contact: [DPO EMAIL / ADDRESS, or "We have not appointed a DPO because [REASON]."]
+```
+Why required: Art. 13(1)(b) — if a DPO exists or is mandatory, their contact must be published.
+
+## 3. Purposes and lawful basis (one block per purpose)
+
+```text
+Purpose: [e.g. "Account creation and service delivery"]
+  Data used: [CATEGORIES]
+  Lawful basis: [consent | contract | legal obligation | vital interests |
+                 public task | legitimate interests]
+  If legitimate interests, the interest is: [STATE IT; LIA on file dated [DATE]]
+```
+Why required: Art. 13(1)(c) — purposes and the lawful basis *per purpose* are mandatory; legitimate interest must name the interest.
+
+## 4. Recipients / categories of recipients
+
+```text
+We share personal data with:
+  - [SUB-PROCESSOR / CATEGORY] — [purpose, e.g. "hosting", "analytics", "email"]
+  - [...]
+```
+Why required: Art. 13(1)(e) — the data subject must know who receives their data.
+
+## 5. International transfers
+
+```text
+We transfer personal data outside the EEA to: [COUNTRY / IMPORTER].
+Transfer mechanism: [2021 Standard Contractual Clauses, module [C2C|C2P|P2P|P2C] |
+                     EU-US Data Privacy Framework (importer certified [DATE]) |
+                     adequacy decision].
+Transfer impact assessment: [completed [DATE] | "not applicable, no transfer"].
+```
+Why required: Art. 13(1)(f) / 44-49 — transfers outside the EEA need a stated mechanism; SCCs without a TIA where one is needed is incomplete.
+
+## 6. Retention
+
+```text
+We retain [CATEGORY] for [PERIOD], then [delete | anonymise].
+Where no fixed period applies, the criteria are: [CRITERIA].
+```
+Why required: Art. 13(2)(a) — retention period or the criteria to set it must be disclosed; "as long as necessary" alone is not enough.
+
+## 7. Data-subject rights
+
+```text
+You have the right to: access, rectification, erasure, restriction, objection,
+and data portability, and to withdraw consent at any time where processing is
+based on consent.
+To exercise any right, contact [EMAIL/CHANNEL]. We respond within one month.
+```
+Why required: Art. 13(2)(b) + Art. 15-22 — the rights list and *how* to exercise it are mandatory.
+
+## 8. Right to lodge a complaint
+
+```text
+You have the right to lodge a complaint with a supervisory authority, in
+particular in your country of residence or work — for example [AUTHORITY NAME,
+e.g. the AEPD in Spain / the APDCAT in Catalonia / the CNIL in France].
+```
+Why required: Art. 13(2)(d) — the right to complain to a supervisory authority is a mandatory disclosure (a frequent omission `verify.sh` checks for).
+
+## 9. Automated decision-making / profiling
+
+```text
+[We do not carry out automated decision-making with legal or similarly
+significant effects. | We use automated decision-making for [PURPOSE];
+the logic is [MEANINGFUL DESCRIPTION] and the consequences are [...].]
+```
+Why required: Art. 13(2)(f) / 22 — existence and meaningful logic of automated decisions must be disclosed.
+
+## 10. Source of data (Art. 14 case only)
+
+```text
+Where we did not collect your data from you directly, the source is: [SOURCE].
+```
+Why required: Art. 14(2)(f) — when data is obtained from a third party, the source must be disclosed.
+
+---
+
+**Before publishing:** have a qualified privacy counsel or your DPO review this policy against the actual processing. This blueprint is a drafting aid, not legal advice.