A privacy policy and cookie banner that match the code

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# A privacy policy and cookie banner that match the code

Most privacy policies are copied templates that do not match what the site does. When the production site launches publicly, people (and regulators) can check. Inventory what the code actually collects, stores and sends to third parties, then make the privacy policy and cookie consent describe exactly that, and make consent actually control the scripts.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Publish policy wording I have not approved.
- Present the draft as legal advice.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Inventory the data

From the code, list every piece of personal data collected (account fields, analytics, IP addresses, payment details, uploads, support messages), where it is stored, how long it is kept, and every third party it is sent to (analytics, email, payments, error tracking, AI APIs, embeds). Include cookies and local storage keys with what sets them.

### 2. Compare with the policy

Read the current privacy policy and cookie policy and list every mismatch: data collected but not mentioned, third parties missing, retention periods that are wrong, claims the code contradicts. Show me the list before changing any wording.

### 3. Make consent real

Scripts and cookies that need consent where the site's users are (analytics with cookies, ads, some embeds) must not load until the visitor agrees, and rejecting must be as easy as accepting. Strictly necessary cookies (sessions, security) need no consent. Remember the choice and let visitors change it from the footer.

### 4. Update the policies

Draft updated policy text that matches the inventory, in plain words, with a last-updated date, and generated where possible from the same list of third parties so it stays in sync. I approve the wording; this is not legal advice and I may have it reviewed.

## Done means

- [ ] Every piece of personal data, cookie and third party in the code is listed.
- [ ] Every mismatch between the policy and the code is listed and fixed in an approved draft.
- [ ] Consent-requiring scripts load only after consent, and rejecting is as easy as accepting.
- [ ] The policies have a last-updated date and visitors can change their choice from the footer.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.