Update privacy policy
Skill flavien-ia/hypervibe-harness/skills/_update-privacy-policy
Internal helper to add or remove subprocessors in the project's RGPD privacy policy registry idempotently. Delegates to the bundled scripts/update-privacy-policy.mjs. Triggered by every add-* skill that introduces a third-party data processor (add-db, add-auth, add-google-auth, add-github-auth, add-stripe, add-email, add-storage, add-analytics, add-agent, add-automation). Not meant to be invoked directly by users.From its SKILL.md
npx -y skills add flavien-ia/hypervibe-harness --skill _update-privacy-policyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
6.0 KB, as published. Nobody here has run it
Update Privacy Policy - Internal helper
Communication
- Detect the user's language from the conversation (the user's own messages, anywhere in the session - not just this invocation: a bare slash command like
/bootstrapcarries no language signal by itself). If nothing in the conversation gives a signal, fall back to the OS locale (node -e "console.log(Intl.DateTimeFormat().resolvedOptions().locale)") before defaulting to English. ALWAYS reply in that language for every user-facing message: questions, progress, confirmations, summaries, errors - including any example text quoted in this skill, which is illustrative and must be translated, never sent verbatim. - Use plain, non-technical business language. Never expose internal script names (*.mjs) or jargon; describe actions in human terms.
- When generating user-facing content for the scaffolded project (UI labels, emails, copy), write it in the user's language too.
- Show progress as a short natural-language checklist (in-progress and done states).
Add or remove subprocessors in the project's RGPD privacy policy registry. Delegates to a bundled Node script - never reimplement the registry edit logic inline.
Architecture
The helper edits <web-root>/src/lib/subprocessors.json (a flat array of subprocessor entries). A thin TS wrapper at <web-root>/src/lib/subprocessors.ts re-exports the JSON with a typed signature. The privacy policy page (src/app/.../politique-de-confidentialite/page.tsx) is generated once by /bootstrap as a pure renderer over the registry - it is never modified by the helper. Only the data file changes when subprocessors are added or removed.
This keeps the page text stable (the user can customize wording) while automating the legally-relevant subprocessor list.
<web-root> is auto-detected: apps/web/ for monorepos, project root otherwise.
Invocation
From the project root, call:
node "${CLAUDE_SKILL_DIR}/../../scripts/update-privacy-policy.mjs" --add <key>
Multiple keys can be added in one call:
node "${CLAUDE_SKILL_DIR}/../../scripts/update-privacy-policy.mjs" --add neon --add resend
Known keys (catalog)
| Key | Trigger skill | Notes |
|---|---|---|
vercel | /bootstrap | Always present - added by bootstrap, never by add-* |
neon | /add-db | |
stripe | /add-stripe | |
google-oauth | /add-google-auth | |
github-oauth | /add-github-auth | |
resend | /add-email (Resend variant) | |
brevo | /add-email (Brevo variant) | EU-resident, lighter compliance |
cloudflare-r2 | /add-storage | |
vercel-analytics | /add-analytics (no-cookie variant) | |
google-analytics | /add-analytics (cookie variant) | Marks requiresConsent: true |
anthropic | /add-agent, /add-workflow (intelligent steps) | |
render | /add-automation (Render variant), /add-agent | Free web service or paid worker, same legal entity either way |
openfreemap | /add-map | The visitor's own browser fetches the tiles, so a third party gets their IP on every page carrying a map |
cloudflare | /new-email-address, /add-domain | DNS and email relay. Distinct from cloudflare-r2: same company, different processing. Flagged manuallyDeclared |
web-push | /add-push-notification | The browser vendor's push service carries the payload. Encrypted (VAPID), so it cannot read it |
manuallyDeclared - the subprocessors the audit cannot see
Most entries are detectable: a package in package.json, an env var, a pattern in the source. Some are not, because they live on a provider's dashboard and leave nothing in the repository - DNS, email routing. /rgpd-audit would then list them as stale and offer to delete them, and a policy "corrected" that way ends up lying.
Entries carrying manuallyDeclared: true are therefore excluded from stale. Set the flag on a new entry only when it has no code footprint at all: an entry that could be detected but is not is a detection rule to write, not a flag to set.
To list the full catalog with all the legal data:
node "${CLAUDE_SKILL_DIR}/../../scripts/update-privacy-policy.mjs" --catalog
Rules
- Always delegate to this helper - never edit
subprocessors.jsoninline. The catalog data (legal name, address, transfer mechanism, etc.) is curated and shouldn't be reinvented. - The helper is idempotent: re-adding an existing key replaces the entry (so catalog updates propagate). Adding then removing is safe.
- If the
subprocessors.jsonfile doesn't exist yet, the helper creates it (along with the TS wrapper). This means/add-*skills can call it even on projects that pre-date this system - but those projects won't have the rendering page until/rgpd-auditis run. - If the script exits non-zero, relay the failure message to the caller - don't retry inline.
- Calling with an unknown key is a hard error (exit 2) - pass an existing catalog key, or extend the catalog in the script first.
Other operations
# List currently registered subprocessors (read-only)
node "${CLAUDE_SKILL_DIR}/../../scripts/update-privacy-policy.mjs" --list
# Remove a subprocessor (e.g., when a service is retired from the project)
node "${CLAUDE_SKILL_DIR}/../../scripts/update-privacy-policy.mjs" --remove brevo
Removals are typically triggered by /clean or by manual cleanup, not by add-* skills.