Add privacy engineering and GDPR guidance for client and platform work

Goal

Make agents detect privacy implications automatically during requirements, design, code review and delivery, without claiming to provide definitive legal advice.

Research scope

GDPR and Danish Data Protection Act; Datatilsynet/EDPB primary guidance. Cover roles (controller/processor), lawful basis, data minimization, retention/deletion, access/export, data subject rights, DPIA screening, breach handling, processor agreements/subprocessors, international transfers, privacy by design and audit evidence. Distinguish legal obligations from engineering recommendations and mark uncertain interpretations for human approval.

Mandatory adoption-first workflow

Inventory existing first-party skills and identify precise gaps; avoid duplication.
Search reputable maintained third-party skills first. Evaluate quality, license/redistribution, security, compatibility, maintenance, provenance and scope.
Prefer adopting a suitable upstream skill with an immutable version/commit pin and a reviewable automated update process; upstream changes must be summarized and tested before bumping the pin. Align with existing issues Bundled upstream skills: reviewable updates and clear redistribution terms #581, Updater PRs state what changed upstream for each moved skill #583 and Review and safely release the temporary git-commit upstream pin #598 rather than duplicating their implementation.
Only author a new first-party skill when documented evaluation shows no adequate candidate. Before implementation, research authoritative standards, primary sources, realistic scenarios, failure modes, acceptance tests and maintenance ownership.
Author first-party skills using the repository's skill-authoring skill and applicable Agent Skills specification/industry conventions; validate metadata, progressive disclosure, triggering, examples and automated evaluation. Never silently claim legal compliance.

Acceptance criteria

Reuse evaluation and source-linked gap analysis documented before building.
Triggers for contact forms, analytics, customer accounts, hosting and personal-data storage.
Concrete checklists, evidence outputs, escalation points and tested positive/negative scenarios.
Official sources dated and maintenance/review plan included.

🔗 Related PRs

#590 - ci: scope engineering-practice skill updates [closed]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

docs: record skill coverage across the portfolio (#655)

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Research brief

Gap. Nothing tells an agent to notice that a change touches personal data, which questions that raises, which of them are legal duties and which are engineering preferences, and when a person has to decide.

Evidence. No incident is on record. The evidence is repeated work: each of these had to work out the same questions from nothing.

business-site#153: how long enquiries and business email may be kept.
business-site#19 and business-site#21: the Danish-law audits before the site and the portal go live.
monorepo#4247: whether hosting and AI terms allow customer data.
ksail#6523: product telemetry that must not identify people.

Where it shows up. Contact handling, customer identity and invoices in the business-site portal; guest replies in wedding-app; client sites; any product that adds analytics or a new hosting provider.

Acceptance scenarios.

Should load: "Add a contact form to the client's site" -> names the personal data, proposes a purpose and legal basis for a person to confirm, sets a retention period, and lists what changes in the privacy notice.
Should load: "Add analytics to the site" -> asks whether it needs consent, who the provider is and where data goes, and points the cookie question to the Danish rules owner (Add Danish business, consumer and accessibility compliance guidance #639).
Should load: "Add customer accounts" -> covers access, export and deletion as features, and what happens to data when an account closes.
Should load: "Move hosting to another provider" or "store uploads in a new bucket" -> processor agreement, location and transfer check, record update.
Near miss: "Who may read this record?" -> application-security. "Write the cookie banner text" -> Add Danish business, consumer and accessibility compliance guidance #639. "A customer's data leaked" -> incident-response, with this skill for the reporting clock.
Must not load: "Rename the user variable".

Already covered by. application-security covers who may reach data and tenant isolation. incident-response covers the response to an incident. Nothing covers purpose, legal basis, retention, people's rights, processors, transfers or impact assessments.

Would something else fix it better? Each product's own instructions must say which data it holds and who is accountable, and no skill replaces that. A CI check cannot know why data is collected. The questions to ask are the reusable part, so a skill is the right carrier.

Out of scope. Legal advice and any statement that something is compliant. Cookie and marketing-consent rules, consumer law and accessibility (#639). Access control (application-security).

Decision record: build `privacy-engineering`

Candidates. Reviewed 2026-11-10.

Candidate	Owner and licence	Reviewed at	Gates	Scores	Verdict
`gdpr-compliant`	github/awesome-copilot, MIT, one contributor	commit `227949a7` (the skill last changed 2026-03-30)	Correctness fails: two of the three reference files it links do not resolve (one is named with a different case, one does not exist), and it states engineering preferences as legal "must" rules, for example masking log addresses, random identifiers and a retention table of its own	F 1, M 1, C 2, T 0, U 2	Reject. The closest candidate. The issue requires law and recommendation to be told apart, and here they are merged. No roles, legal basis, transfer or Danish content
`compliance-check`	anthropics/knowledge-work-plugins, Apache-2.0	commit `e605d8dd`	Not taken to the gates: rejected on fit	F 0, M 2, C 1, T 0, U 2	Reject. Written for an in-house legal team checking a business initiative across many jurisdictions. It states the response time as 30 days where the regulation says one month. It would not load for engineering work
`Privacy-Data-Protection-Skills`	mukul975, Apache-2.0	default branch on 2026-11-10	Correctness cannot be established: 824 skill files	not scored	Reject. Too large to review, and it would flood the skill listing
`secpriv-skill`	facebookresearch, MIT	commit `70e1269a`	Compatibility fails: the file has no frontmatter, so it is not in the open skill format	not scored	Reject. A research procedure that reviews finished code and returns findings as data
`eyesecurity/skills`	Eye Security, GPL-3.0	not read	Licence: copyleft terms need the same redistribution review as share-alike (#581)	not scored	Reject for now

What was read. gdpr-compliant: the whole entry file, and its folder listing for the references. compliance-check: the whole file. secpriv-skill: the opening of the file and the repository layout. The other two were not read; they fail before content matters.

Why build. No candidate separates legal duties from recommendations, none covers Danish law, and the closest one fails on correctness.

Sources the skill is written against (checked 2026-11-10): the GDPR's own text; the Danish Data Protection Act as consolidated in act no. 289 of 8 March 2024, read in the official legal database; and the Danish Data Protection Agency's published guidance on secure transmission (updated 2025-10-17), breach handling (May 2025) and impact assessments. One fact changed against common belief while checking: the Danish age for a child's own consent to online services is now 15, not 13.

Known defects. None yet: the skill is being written. It will carry its sources, the date each was checked, and a review plan.

Description cost. Reported on the pull request, with the target of 400 characters or fewer.

Acceptance scenarios. Results are recorded on the pull request after the skill is installed from its head.

What would change this decision. A maintained upstream skill that separates law from practice and covers EU and Danish rules would replace this one.

🤖 Generated with Claude Code

fix(agentic-engineering): correct the privacy-engineering skill after…

fix(agentic-engineering): label authority practice and split one mixe…

fix(agentic-engineering): keep advice out of the law bullet in privac…

fix(agentic-engineering): address the review of the privacy and Danis…

feat(agentic-engineering): add the privacy-engineering and danish-bus…

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Done in #683, released as agentic-engineering 7.6.0. This note completes the decision record above.

Acceptance criteria.

The reuse evaluation and the gap analysis were posted here before building. Five upstream candidates were rejected; the coverage page records why.
The description and the worked scenarios cover contact forms, analytics, customer accounts, hosting and stored personal data. From the description alone a fresh agent chose the skill for each of those.
It has checklists per scenario, the evidence each change leaves, and a list of when to stop and who decides. A fresh agent ran a contact form with a health question through it, and the skill was corrected from what that found.
Every legal statement names its article or section. The sources are listed with the date read and a review plan, next due by 2027-05-10.

What changed during trial and review. The skill at first gave no way to finish the legal-basis step for health data and steered away from consent; both were fixed. The review added prior consultation with the authority, the exception to breach reporting, legal claims as a ground for keeping data, identifiers in audit logs, and the difference between a processor and another recipient. One fact I had wrong from memory was caught by reading the act: the Danish age for a child's own consent online is 15.

Description cost. 408 characters.

Known limits. It is engineering guidance, not legal advice, and it has not been reviewed by a lawyer. The Danish authority's list of processing that always needs an impact assessment is pointed to, not restated, because I could not read the file here. The review fixes were not re-tried by the fresh agent. Whether agents load the skill in daily work is for #651 to measure.

🤖 Generated with Claude Code

Navigation Menu

Repository navigation

Add privacy engineering and GDPR guidance for client and platform work #638

Goal

Research scope

Mandatory adoption-first workflow

Acceptance criteria

Research brief

Decision record: build `privacy-engineering`

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Add privacy engineering and GDPR guidance for client and platform work #638

Description

Goal

Research scope

Mandatory adoption-first workflow

Acceptance criteria

Activity

coderabbitai commented on Nov 4, 2026

devantler commented on Nov 10, 2026

Research brief

Decision record: build privacy-engineering

devantler commented on Nov 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

Decision record: build `privacy-engineering`