@damiangilgonzalez/harness 1.3.7

package/skills/gcp-essentials/references/iam-and-auth.md

@@ -0,0 +1,94 @@
+# IAM & auth
+
+Depth for the IAM section of SKILL.md. Predefined roles, keyless CI, impersonation,
+drift detection.
+
+## Predefined roles for a typical product
+
+Prefer these Google-maintained roles over primitives or custom roles. Bind them to the
+service's dedicated SA at the narrowest resource scope the role supports.
+
+| Need | Role | Scope it to |
+|------|------|-------------|
+| Connect to Cloud SQL from the workload | `roles/cloudsql.client` | project |
+| Read/write objects in one bucket | `roles/storage.objectAdmin` | the bucket |
+| Read object content only | `roles/storage.objectViewer` | the bucket |
+| Read one secret's value | `roles/secretmanager.secretAccessor` | the secret |
+| Invoke a private Cloud Run service | `roles/run.invoker` | the service |
+| Push/pull container images | `roles/artifactregistry.writer` | the repo |
+| Write logs/metrics from the app | usually implicit on Cloud Run runtime SA | — |
+
+Bind at resource scope when possible — e.g. a secret, not the project:
+
+```bash
+gcloud secrets add-iam-policy-binding db-password \
+  --member="serviceAccount:api-sa@acme-prod.iam.gserviceaccount.com" \
+  --role="roles/secretmanager.secretAccessor"
+```
+
+## Workload Identity Federation for GitHub Actions (keyless)
+
+No JSON key downloaded, ever. GitHub's OIDC token is exchanged for short-lived GCP
+credentials.
+
+```bash
+# 1. A pool + an OIDC provider that trusts GitHub's issuer
+gcloud iam workload-identity-pools create github \
+  --location=global --display-name="GitHub Actions"
+
+gcloud iam workload-identity-pools providers create-oidc github-oidc \
+  --location=global --workload-identity-pool=github \
+  --display-name="GitHub OIDC" \
+  --issuer-uri="https://token.actions.githubusercontent.com" \
+  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
+  --attribute-condition="assertion.repository=='acme/api'"
+
+# 2. Let the deploy SA be impersonated only from that repo
+PROJECT_NUM=$(gcloud projects describe acme-prod --format='value(projectNumber)')
+gcloud iam service-accounts add-iam-policy-binding \
+  deployer@acme-prod.iam.gserviceaccount.com \
+  --role="roles/iam.workloadIdentityUser" \
+  --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUM}/locations/global/workloadIdentityPools/github/attribute.repository/acme/api"
+```
+
+In the workflow, use `google-github-actions/auth` with the provider resource name and
+`service_account` — never a `credentials_json` secret. The `attribute-condition`
+pinning the exact repo is the security boundary; without it any repo could mint
+credentials.
+
+## Service account impersonation
+
+Run a one-off command *as* a service account without holding its key. The caller needs
+`roles/iam.serviceAccountTokenCreator` on the target SA.
+
+```bash
+gcloud storage ls gs://acme-prod-uploads \
+  --impersonate-service-account=api-sa@acme-prod.iam.gserviceaccount.com
+```
+
+Use this to test that an SA actually has the access you think it does — least surprise
+before deploy.
+
+## IAM Recommender (catch drift)
+
+The Recommender flags roles a member has not used in 90 days, so you can prune
+over-grants. Review it on a schedule.
+
+```bash
+gcloud recommender recommendations list \
+  --project=acme-prod --location=global \
+  --recommender=google.iam.policy.Recommender \
+  --format="table(content.overview)"
+```
+
+## IAM Conditions
+
+Attach a condition to narrow a binding by time or resource attribute — e.g. access to
+objects under one prefix only.
+
+```bash
+gcloud projects add-iam-policy-binding acme-prod \
+  --member="serviceAccount:api-sa@acme-prod.iam.gserviceaccount.com" \
+  --role="roles/storage.objectViewer" \
+  --condition='expression=resource.name.startsWith("projects/_/buckets/acme-prod-uploads/objects/public/"),title=public-prefix-only'
+```

package/skills/gcp-essentials/references/networking-and-sql.md

@@ -0,0 +1,74 @@
+# Networking & Cloud SQL
+
+Depth for the Cloud SQL and VPC parts of SKILL.md.
+
+## Cloud Run egress: Direct VPC egress, not the legacy connector
+
+To reach private IPs (a Cloud SQL private instance, an internal service) from Cloud
+Run, prefer **Direct VPC egress** over the older Serverless VPC Access connector —
+fewer moving parts, lower latency, no connector VM to size or pay for.
+
+```bash
+gcloud run deploy api --region=europe-west1 \
+  --service-account=api-sa@acme-prod.iam.gserviceaccount.com \
+  --network=projects/acme-prod/global/networks/default \
+  --subnet=projects/acme-prod/regions/europe-west1/subnetworks/default \
+  --vpc-egress=all-traffic
+```
+
+- `--vpc-egress=all-traffic` routes all outbound through the VPC. The older explicit
+  Direct-VPC-egress value is deprecated in favour of `all-traffic`.
+- `--vpc-egress=private-ranges-only` sends only RFC-1918 traffic through the VPC and
+  lets public traffic exit directly — use it when only the DB is private.
+
+The legacy `--vpc-connector` still works but is no longer the default recommendation;
+do not provision a new connector for greenfield work.
+
+## Cloud SQL private IP
+
+Disable the public IP and give the instance a private address on your VPC. This is the
+single biggest attack-surface reduction for a database.
+
+```bash
+# One-time: allocate a range and peer it (Service Networking)
+gcloud compute addresses create google-managed-services-default \
+  --global --purpose=VPC_PEERING --prefix-length=16 \
+  --network=projects/acme-prod/global/networks/default
+gcloud services vpc-peerings connect \
+  --service=servicenetworking.googleapis.com \
+  --ranges=google-managed-services-default \
+  --network=default --project=acme-prod
+
+# Create the instance with private IP, no public IP.
+# --edition=ENTERPRISE is required: POSTGRES_16+ defaults to Enterprise Plus, which
+# cannot run the shared-core db-f1-micro tier, so the create fails without it.
+gcloud sql instances create acme-db \
+  --database-version=POSTGRES_16 --edition=ENTERPRISE \
+  --region=europe-west1 --tier=db-f1-micro \
+  --no-assign-ip \
+  --network=projects/acme-prod/global/networks/default
+```
+
+PSC (Private Service Connect) is the alternative when you need the instance reachable
+from multiple VPCs or projects; enable it with `--enable-private-service-connect` and
+allow the consumer projects.
+
+## Cloud SQL Auth Proxy (for outside-VPC connections)
+
+The proxy gives short-lived client certs and TLS 1.3 without managing certificates. Use
+it for **local dev** or any non-serverless host — Cloud Run does **not** need it (it
+uses the `/cloudsql/...` socket via `--add-cloudsql-instances`).
+
+```bash
+# Local dev against a private-IP instance over the proxy
+./cloud-sql-proxy --private-ip acme-prod:europe-west1:acme-db
+# then connect your client to 127.0.0.1:5432
+```
+
+## Connection pooling
+
+Cloud SQL has a hard `max_connections` ceiling and Cloud Run can fan out to many
+instances, each opening its own pool — you will exhaust connections under load. Keep
+each instance's pool small (e.g. a few connections) and, for high concurrency, front
+the database with a pooler (PgBouncer / a managed proxy) rather than raising
+`max_connections`. Schema and query tuning beyond this is `postgresdb` territory.

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,159 @@
+---
+name: gdpr-privacy
+description: "Use when producing the GDPR artifacts a product publishes or hands over: a privacy policy true to what it processes, a cookie/consent banner, a lawful basis per purpose, an Art. 28 DPA, an SCC transfer mechanism, or a DSAR flow. Drafts for counsel review. NOT internal retention rules (that is `data-policy`), NOT consumer ToS (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.
+
+## Stakes, and what isn't yours
+
+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 |
+
+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 (banlist rationale in `references/dsar-and-consent.md`).

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: Drafting the privacy policy under GDPR, asked in Spanish — matched by meaning, not keyword.
+  - prompt: "Revisa el banner de cookies del web perquè el rebuig sigui tan fàcil com acceptar."
+    why: Cookie-banner review against the reject-parity rule, asked in Catalan.
+
+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.