skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/experience-design/skills/ux-writing/examples/team-invite-flow.md

@@ -0,0 +1,66 @@
+# Worked example — the copy for a team invite flow
+
+## Input given to the skill
+
+> We're adding "invite teammates" to Northwind Boards (project management SaaS). Flow: Team page →
+> Invite button → modal with an email field (multiple, comma separated) and a role picker
+> (Admin / Member) → send. There's also a Pending invites tab where you can revoke an invite. Right
+> now the modal says "Add users" and the button says "Submit", and the Team page calls them
+> "members" while the billing page says "seats". Voice: friendly but not cute. Web only, English only
+> for now.
+
+## Output
+
+# Interface copy: team invite flow
+
+**Voice:** friendly but not cute (given) → plain, "you", sentence case, no exclamation marks
+**Platform:** web · **Localised:** no, so budgets have no growth allowance
+**Assumptions to confirm first:**
+- There is a per-send invite limit (`{limit}` below, value not given).
+- Admins can manage billing and members, and Members can't. The role hint depends on this, so confirm it before shipping.
+- Invites go out by email with a join link, and revoking one kills the link without emailing the invitee.
+
+Character counts include spaces and count each `{placeholder}` as written. Leave room for the real value: an email address can run 30+ characters.
+
+### String table
+
+| ID | Screen | Slot | Context | Budget | Recommended (count) | Variant (count, why) |
+|---|---|---|---|---|---|---|
+| `invite.title` | Invite | page title | Opens from Team › Invite | 40 | "Invite people to your workspace" (31) | "Invite teammates" (16, shorter) |
+| `invite.email.label` | Invite | label | Email field | 30 | "Email addresses" (15) | "Emails" (6, shorter) |
+| `invite.email.hint` | Invite | hint | Under the email field | 80 | "Separate addresses with commas. You can invite up to {limit} at once." (69) | "Add one or more emails, separated by commas." (44, shorter; drops the limit) |
+| `invite.role.label` | Invite | label | Role picker | 30 | "Role" (4) | "Their role" (10, warmer) |
+| `invite.role.hint` | Invite | hint | Under the role picker | 80 | "Admins can manage billing and members. Members can use the workspace." (69) | "Choose what they can do in this workspace." (42, shorter; less explicit) |
+| `invite.submit` | Invite | button | Primary action | 20 | "Send invites" (12) | "Invite" (6, shorter) |
+| `invite.error.email_format` | Invite | error | An address isn't a valid email | 100 | "“{value}” isn't an email address. Check it for typos, like a missing @." (71) | "Check “{value}”. It needs an @ and a domain, like sam@northwind.example." (72, more explicit) |
+| `invite.error.already_member` | Invite | error | Address belongs to an existing member | 100 | "{email} is already in this workspace. Remove it to send the other invites." (74) | "{email} is already a member, so we won't invite them again." (59, warmer; no action) |
+| `invite.error.limit` | Invite | error | More addresses than the limit | 100 | "You can invite up to {limit} people at once. Remove {excess} to continue." (73) | "That's more than {limit}. Send these in two batches." (52, shorter) |
+| `invite.error.network` | Invite | error | Request failed or timed out | 100 | "We couldn't send the invites. Check your connection and try again." (66) | "Invites not sent. Try again in a moment." (40, shorter) |
+| `invite.loading` | Invite | loading | After pressing Send invites | 40 | "Sending invites…" (16) | "Sending {n} invites…" (20, more explicit) |
+| `invite.success` | Invite | toast | All invites sent | 60 | "Invites sent to {n} people" (26) | "{n} invites sent. They'll get an email." (39, more explicit) |
+| `pending.empty.title` | Pending invites | empty | No pending invites | 40 | "No pending invites" (18) | "Nobody's waiting to join" (24, warmer) |
+| `pending.empty.body` | Pending invites | empty | Under the empty title | 100 | "People you invite show here until they accept." (46) | "Invites you send will appear here." (34, shorter) |
+| `pending.empty.action` | Pending invites | button | Empty state action | 20 | "Invite people" (13) | "Send an invite" (14, warmer) |
+| `pending.revoke.title` | Pending invites | dialog title | Revoke an invite | 40 | "Revoke invite for {email}?" (26) | "Revoke this invite?" (19, shorter; drops the name) |
+| `pending.revoke.body` | Pending invites | dialog body | Revoke dialog | 160 | "The link in their email will stop working. You can invite them again later." (75) | "They won't be able to join with this invite. You can send a new one any time." (77, warmer) |
+| `pending.revoke.confirm` | Pending invites | button | Destructive confirm | 20 | "Revoke invite" (13) | "Revoke" (6, shorter) |
+| `pending.revoke.cancel` | Pending invites | button | Dismiss | 20 | "Keep invite" (11) | "Cancel" (6, shorter; less clear) |
+
+**Recommendations, briefly:** use the recommended column throughout. "Send invites" says what the button does where "Submit" doesn't. The already-member error keeps the action ("Remove it…") because the variant leaves the user unsure whether the other invites went. "Keep invite" beats "Cancel" in the revoke dialog, because "Cancel" next to "Revoke invite" reads as "cancel the invite".
+
+### Terminology
+
+| Concept | Use | Avoid | Notes |
+|---|---|---|---|
+| A person with access | member | user, seat, teammate (in UI labels) | The billing page says "seats". Change it to "members", or explain "you pay per member". "Teammates" only in the page title variant. |
+| The shared space | workspace | team, account, organisation | The Team page title already says "Team". Rename it to "Members", or flag it for `information-architecture`. |
+| Asking someone to join | invite (verb and noun) | add, add users | Replaces "Add users" in the current modal |
+| Withdrawing an invite | revoke | cancel, delete | Keeps "Cancel" free to mean "close this dialog" |
+| Permission level | role | permission, access level | Role names: Admin, Member |
+
+### Open questions
+
+- What is `{limit}`, the most invites per send? The hint and the limit error need it.
+- Does an invite expire? If so, add an `invite.expired` error for the invitee's landing page and say the expiry in the success toast.
+- Can a Member invite, or only an Admin? If only Admins can, Members need a disabled-state hint on the Invite button.
+- Should the billing page change from "seats" to "members"? That's a product decision, not a copy one.

skilldrop_cli/data/packs/experience-design/skills/ux-writing/manifest.json

@@ -0,0 +1,41 @@
+{
+  "name": "ux-writing",
+  "version": "0.1.0",
+  "description": "Write the interface copy for a flow or component — buttons, labels, hints, errors, empty states, confirmations, loading and success messages — as a string table where each string has its context, a character budget, a recommended version and one variant, with error messages that say what happened and what to do next, and a terminology list so the same thing has the same name everywhere. Use when the user wants UI copy, microcopy, button text, error messages, empty states, \"write the strings for this screen\", or \"our wording is inconsistent\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "accessibility-audit",
+    "brand-kit",
+    "content-design",
+    "design-system-spec",
+    "guide-builder"
+  ],
+  "handoff": [
+    {
+      "to": "accessibility-audit",
+      "when": "the strings are built into a working UI",
+      "purpose": "Check the built flow against WCAG, which a string table can't prove.",
+      "fallback": "If accessibility-audit is absent, list the checks still owed: errors announced to screen readers, labels tied to fields, and link text that makes sense out of context."
+    }
+  ],
+  "tags": [
+    "ux-writing",
+    "microcopy",
+    "ui-copy",
+    "error-messages",
+    "content",
+    "terminology"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Short-form writing to fixed slot rules and character budgets, plus a terminology consistency pass. Bounded generation with clear checks."
+  }
+}

skilldrop_cli/data/packs/experience-design/skills/ux-writing/templates/string-table.md

@@ -0,0 +1,22 @@
+# Interface copy: {flow or component}
+
+**Voice:** {from brand.json / style guide / default: plain, direct, "you", sentence case, no exclamation marks}
+**Platform:** {web / iOS / Android} · **Localised:** {yes — budgets allow ~30% growth / no}
+**Assumptions to confirm first:** {list, or "none"}
+
+## String table
+
+| ID | Screen | Slot | Context (when it shows) | Budget | Recommended (count) | Variant (count, why) | Notes |
+|---|---|---|---|---|---|---|---|
+| {screen.slot.state} | {screen} | {button / label / hint / error / empty / loading / success / dialog / toast} | {trigger} | {n} | "{string}" ({n}) | "{string}" ({n}, shorter / warmer / more explicit) | {why recommended} |
+
+## Terminology
+
+| Concept | Use | Avoid | Notes |
+|---|---|---|---|
+| {concept} | {term} | {terms} | {where the banned term already appears} |
+
+## Open questions
+
+- {Error case or limit engineering must confirm}
+- {State nobody has defined}

skilldrop_cli/data/packs/grc/pack.json

@@ -0,0 +1,57 @@
+{
+  "description": "Governance, risk and compliance drafts for compliance leads, DPOs and risk owners: a risk register with a checked heat map, a GDPR data protection impact assessment, and a SOC 2 control-to-evidence map, each prepared for a qualified person to review.",
+  "display_name": "Governance, risk and compliance",
+  "keywords": ["grc", "risk register", "dpia", "gdpr", "soc 2", "compliance", "audit evidence", "privacy"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/grc/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "non-technical",
+    "prerequisites": ["A list of the risks you already worry about, with an owner for each if you know them"],
+    "starter-task": "Turn a list of worries into a scored, owned risk register",
+    "starter-prompt": "Build a risk register for our office relocation project. Risks: the lease on the new floor isn't signed yet (owner: Facilities Manager, Dana Cole), the network fit-out might slip past the move date (owner: IT Manager, Raj Patel), and staff may push back on desk sharing (owner: HR Business Partner, Lena Fox). Use a 5x5 scale; today is 2026-10-01.",
+    "verification": "risk-register writes a CSV where each risk has a cause, an event and a consequence, inherent and residual scores on a defined 5x5 scale, a named owner and a treatment with a date; its check script prints PASS, a heat map, and the top risks needing a decision.",
+    "recovery": "If the script fails, read its error lines: each names the row and the field to fix. If risk-register does not activate, ask for it by name (\"use risk-register\")."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "An audit, a regulator, a new processing activity or a risk committee needs a written, defensible view of what could go wrong and what you do about it.",
+    "you_bring": [
+      "the scope: a project, a product, a business unit or the whole company",
+      "the risks you know about and who owns each",
+      "for a DPIA: what personal data you process, why, where it goes and how long you keep it",
+      "for SOC 2: the Trust Services Criteria in scope, the report type, and your controls list if you have one"
+    ],
+    "steps": [
+      {
+        "skill": "risk-register",
+        "you_do": "Give it the scope, the risks and the owners.",
+        "you_get": "A register CSV with each risk as cause, event and consequence, inherent and residual scores on a defined scale, treatments with dates, a checked heat map, and the top risks needing a decision.",
+        "decide": "Which risks to accept, fund or avoid."
+      },
+      {
+        "skill": "dpia",
+        "you_do": "For any activity that processes personal data and looks high risk, describe the processing, the data and the recipients.",
+        "you_get": "A DPIA draft in the structure GDPR requires, with a data inventory, lawful basis per purpose, risks to individuals, measures, residual risk, a view on prior consultation, and questions for the DPO.",
+        "decide": "Whether the DPO signs off, asks for more measures, or recommends prior consultation."
+      },
+      {
+        "skill": "soc2-evidence-map",
+        "you_do": "Name the criteria in scope, Type I or Type II, the audit period, and your controls and systems.",
+        "you_get": "A control-to-criteria map with the evidence an auditor will ask for, where it lives, who owns it, how often it is produced, and the gaps, as a table and a CSV."
+      },
+      {
+        "skill": "doc-critique",
+        "you_do": "Run it on the DPIA or the evidence map before it goes to the DPO or the auditor.",
+        "you_get": "A verdict and severity-tagged findings with a fix for each.",
+        "decide": "Send it, fix it, or go back for missing facts."
+      }
+    ],
+    "you_end_with": "A risk register you can keep up to date, a DPIA draft ready for the DPO, and an evidence map that tells each control owner what to collect before the audit."
+  }
+}

skilldrop_cli/data/packs/grc/skills/dpia/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: dpia
+description: Draft a data protection impact assessment (DPIA) for one processing activity in the structure GDPR Article 35(7) requires — a systematic description of the processing and its purposes, necessity and proportionality, risks to the rights and freedoms of individuals, and the measures to address them — with a data inventory (categories, special category data, data subjects, sources, recipients, transfers outside the EEA, retention), the lawful basis per purpose, a likelihood × severity risk table scored for harm to people, residual risk, a view on prior consultation, and the open questions for the DPO. Use when the user needs a DPIA or PIA, is launching something that processes personal data in a new or risky way, or asks "do we need a DPIA", "write the DPIA for…", "privacy impact assessment".
+---
+
+# dpia
+
+You draft the DPIA a data protection officer can review, challenge and sign: one processing
+activity, described precisely enough that a regulator could follow what happens to the data,
+with risks scored for **the people the data is about**, not for the company. The output is
+a Markdown document in the order GDPR Article 35(7) sets out, plus the questions only the
+DPO or the business can answer. You prepare material for a qualified person (the DPO or
+privacy counsel) to review; it is not legal advice, and the controller owns the decision.
+
+## How to respond
+
+1. **Ask once for what is missing, in one message.** Take what is already given. Ask for at
+   most two things, and say what you will assume for the rest:
+   - **The processing activity:** what happens, to whose data, for what purpose, using which
+     systems and vendors. One activity per DPIA; split "the new HR platform" into its
+     purposes if they differ (payroll, performance, monitoring).
+   - **The facts you can't infer:** where vendors process data, retention periods, and
+     whether any decision about a person is made without human review.
+
+   Everything else you can't confirm goes in the draft as `[to confirm: …]` and in the DPO
+   questions. Never fill a retention period, a vendor location or a lawful basis decision
+   with a plausible guess and present it as fact.
+
+2. **Screen first: say whether a DPIA looks required, and why.** Check the activity against
+   the Article 35(3) cases and the nine criteria in the EDPB-endorsed guidelines (in
+   [`reference.md`](reference.md)). Name each criterion that applies. Two or more usually
+   means a DPIA is needed; also check the supervisory authority's own list. If none apply,
+   say so and offer a short screening record instead of a full DPIA.
+
+3. **Describe the processing systematically** (Art. 35(7)(a)). Build the data inventory
+   from [`templates/dpia.md`](templates/dpia.md): data categories, special category data
+   (Art. 9(1)) and criminal offence data called out separately, data subjects, sources,
+   recipients and processors, transfers outside the EEA with the transfer mechanism,
+   retention per category, and the data flow from collection to deletion. Include the
+   legitimate interest pursued where that is the basis.
+
+4. **Give a lawful basis per purpose,** not one for the whole activity. Each purpose gets one
+   Article 6(1) basis; special category data also needs an Article 9(2) condition. Flag
+   these as problems, not facts:
+   ✅ "Purpose: shift allocation. Basis: legitimate interests [to confirm: balancing test]."
+   ❌ "Lawful basis: consent." for employees, where the power imbalance makes consent hard
+   to rely on; ❌ "Basis: GDPR compliance" (not a basis).
+
+5. **Assess necessity and proportionality** (Art. 35(7)(b)). For each purpose: is the
+   processing needed, could less data or a less intrusive method achieve it, how long is
+   each category kept and why, how are people told (Arts. 13/14), and how do they exercise
+   their rights. Say plainly where the design collects more than the purpose needs.
+
+6. **Score the risks to individuals** (Art. 35(7)(c)). Each risk names the harm to a person:
+   discrimination, financial loss, loss of confidentiality, loss of control over their data,
+   being unable to exercise a right, physical harm, distress. Score likelihood (remote,
+   possible, probable) × severity (minimal, significant, severe) = low, medium or high, using
+   the matrix in [`reference.md`](reference.md).
+   ✅ "Warehouse staff with a disability are ranked as low performers and face disciplinary
+   review." ❌ "Reputational damage to Acme." ❌ "Regulatory fine." (company risks belong in
+   `risk-register`).
+
+7. **List measures against each risk** (Art. 35(7)(d)): what changes the design, who owns
+   it, and whether it is in place or planned. Then rescore as **residual** risk, counting
+   only measures the business has agreed to.
+
+8. **Give a view on prior consultation.** If any residual risk stays high, say that prior
+   consultation with the supervisory authority under Article 36 looks needed and why. If
+   none does, say so. This is a view for the DPO, not a decision.
+
+9. **End with the DPO questions and sign-off block.** Number the open questions; each names
+   who can answer it. Leave the DPO advice, the decision and the sign-off fields blank.
+
+10. **Emit the document** in the order of [`templates/dpia.md`](templates/dpia.md), with the
+    not-legal-advice line once, at the top.
+
+**Non-interactive runs** (subagent, CI, headless): unconfirmed details (retention, vendor
+locations, the balancing test) become `[to confirm: …]` entries and DPO questions. If the
+processing activity itself is not described (no data, no purpose), emit
+`BLOCKED: need the processing activity: what personal data, whose, for what purpose, and which systems or vendors`.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md): what Article 35(7) requires, the screening criteria, lawful bases and special category conditions, transfer mechanisms, the risk matrix, and prior consultation
+- [`templates/dpia.md`](templates/dpia.md): the DPIA skeleton, section by section
+- [`examples/acme-warehouse-performance.md`](examples/acme-warehouse-performance.md): worked example, a warehouse productivity analytics tool for a fictional company
+
+## Quality bar
+
+- **The four Article 35(7) parts are all present,** in order: description and purposes, necessity and proportionality, risks to individuals, measures.
+- **Risks are harms to people,** scored for likelihood and severity to them. No company-impact rows.
+- **Every purpose has its own lawful basis,** and special category data has an Article 9(2) condition or an open question saying it lacks one.
+- **Transfers outside the EEA name the destination and the mechanism,** or are marked `[to confirm]`.
+- **Every unknown is visible:** `[to confirm]` in the body and a numbered DPO question, never a guess written as fact.
+- **Residual risk counts only agreed measures,** and the prior consultation view follows from it.
+- **Article numbers cited are ones the regulation actually contains** for that point; when unsure, describe the requirement without a number.
+
+## When to use this skill
+
+- ✅ A new product feature, system or vendor that processes personal data in a new way
+- ✅ Employee monitoring, profiling, scoring, location tracking, or automated decisions about people
+- ✅ Large-scale processing of health, biometric or other special category data
+- ✅ Screening "do we need a DPIA for this?" before a project starts
+- ✅ Refreshing an old DPIA after the processing changed
+
+## When NOT to use this skill
+
+- ❌ Security threats against a system design: use `threat-model`, and feed its findings into the measures section here
+- ❌ Threats to an AI agent's tools and prompts: use `agent-threat-model`
+- ❌ Rules for staff using AI tools: use `ai-usage-policy`
+- ❌ Business risks to the company, scored for the company: use `risk-register`
+- ❌ Mapping controls to SOC 2 audit evidence: use `soc2-evidence-map`
+
+## Anti-patterns to avoid
+
+- ❌ **Scoring risk to the company.** "Fine of up to 4% of turnover" is not a DPIA risk. The question is what happens to the person.
+- ❌ **One lawful basis for everything.** Payroll, performance scoring and marketing are different purposes with different bases.
+- ❌ **Consent from employees by default.** Use it only where refusing has no consequence for the person.
+- ❌ **"Data is encrypted" as the only measure.** Encryption doesn't address unfair scoring, excessive retention or lack of transparency.
+- ❌ **"Retention: as long as necessary."** Give a period per category, or mark it `[to confirm]`.
+- ❌ **Invented article numbers.** A wrong citation in a DPIA costs the DPO's trust in the whole document.
+- ❌ **Filling the DPO's sign-off.** The draft leaves advice, decision and signature blank.
+- ❌ **The whole platform in one DPIA.** Assess one processing activity; list the others as separate DPIAs to do.

skilldrop_cli/data/packs/grc/skills/dpia/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a DPIA for our new employee location-tracking app",
+    "should_trigger": true
+  },
+  {
+    "query": "Do we need a data protection impact assessment for using CCTV with face recognition in our stores?",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft the privacy impact assessment for the CRM migration, including the lawful basis and transfers to the US",
+    "should_trigger": true
+  },
+  {
+    "query": "Our DPO wants a GDPR Article 35 assessment before we launch the loyalty scoring feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Threat model the new patient portal architecture using STRIDE",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an acceptable-use policy for staff using ChatGPT and Copilot",
+    "should_trigger": false
+  },
+  {
+    "query": "Assess the prompt-injection and tool-misuse risks of our customer support agent",
+    "should_trigger": false
+  },
+  {
+    "query": "Update the company risk register and show me the heat map",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/grc/skills/dpia/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "dpia",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Northwind Health is adding a symptom checker to its patient app: users in Germany and France type symptoms, an AI model suggests whether to book a GP, a pharmacist or urgent care, and the conversation is stored with their patient record. The model is hosted by a vendor in Ireland and we send anonymised transcripts to a US research partner to improve it. Write the DPIA. Our DPO is Claire Martin.",
+      "assertions": [
+        "The draft follows the Article 35(7) structure: systematic description and purposes, necessity and proportionality, risks to individuals, and measures",
+        "Health data is identified as special category data and given an Article 9(2) condition or an open question saying one is needed",
+        "Each purpose (triage suggestion, storing with the record, research sharing) has its own lawful basis rather than one basis for the whole activity",
+        "The transfer to the US research partner is treated as a transfer outside the EEA with a mechanism named or marked to confirm, and the 'anonymised' claim is questioned rather than accepted",
+        "Risks are scored as harms to patients (for example, a wrong triage suggestion delaying care), not as fines or reputational harm to Northwind",
+        "Residual risk counts only agreed measures, and the draft gives a view on whether prior consultation looks needed",
+        "Retention periods and other facts not in the prompt are marked to confirm and listed as DPO questions, not invented",
+        "The DPO advice and sign-off fields are left blank, and the not-legal-advice statement appears once"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/grc/skills/dpia/examples/acme-warehouse-performance.md

@@ -0,0 +1,159 @@
+# Worked example: Acme Logistics warehouse performance analytics
+
+A fictional company. The input is what a business owner might send; the output is the DPIA
+draft, shortened where sections repeat the same pattern.
+
+## Input given to the skill
+
+> We're rolling out "PickPulse" at our two Dutch warehouses (about 600 staff, including
+> agency workers). It takes the handheld scanner data — every scan, timestamp, location in
+> the aisle, idle time — and gives each picker a daily productivity score against a target.
+> Team leads see a ranked list, and anyone under 85% of target for two weeks gets flagged
+> for a performance conversation. It also uses the absence calendar to adjust targets for
+> people coming back from sick leave. The vendor is US-based, hosted on AWS in Frankfurt,
+> but their support team in the US can access the data. We'd keep the scan data for two
+> years. Can you write the DPIA? Our DPO is Marieke de Vries.
+
+The skill asked one question, "Does a flag lead straight to a warning or other sanction, or
+does a team lead always review it first?", and the user answered: "A team lead reviews, but
+in practice they mostly follow the flag."
+
+---
+
+# DPIA: Picker productivity scoring with PickPulse
+
+> Draft prepared for review by the DPO. It is not legal advice; the controller decides.
+> Items marked `[to confirm: …]` are unverified and repeated in §7.
+
+| | |
+|---|---|
+| Controller | Acme Logistics B.V. `[to confirm: legal entity]` |
+| Processing activity | Daily productivity scoring and flagging of warehouse pickers from scanner data |
+| Business owner | `[to confirm: name, role]` |
+| DPO | Marieke de Vries |
+| Version / date | 0.1 draft / 2026-10-01 |
+| Status | Draft for DPO advice |
+
+## 1. Screening
+
+| Criterion | Applies? | Why |
+|---|---|---|
+| Evaluation or scoring | yes | A daily productivity score per picker |
+| Automated decision-making with legal or similar effect | possibly | Flags drive performance conversations; team leads "mostly follow the flag", so human review may not be meaningful |
+| Systematic monitoring | yes | Every scan, location and idle period, all shift |
+| Sensitive or highly personal data | yes | Sick-leave data used to adjust targets is health data |
+| Large scale | possibly | About 600 people, continuous collection |
+| Matching or combining datasets | yes | Scanner data combined with the absence calendar |
+| Vulnerable data subjects | yes | Employees and agency workers, in an imbalance of power with the employer |
+| Innovative technology | no | Productivity analytics is established |
+| Prevents exercising a right or using a service | no | |
+
+**Conclusion:** DPIA required. At least five criteria apply. The Dutch supervisory
+authority's list `[to confirm: checked by DPO]` is also likely to cover employee monitoring.
+
+## 2. Description of the processing (Art. 35(7)(a))
+
+**What happens:** scanners record each scan → PickPulse ingests events every 15 minutes →
+scores computed nightly against targets, adjusted for return from sick leave → team leads
+see a ranked list → pickers under 85% for two weeks are flagged → team lead holds a
+performance conversation → scan data deleted after two years.
+
+**Purposes:**
+
+| # | Purpose | Lawful basis (Art. 6(1)) | Art. 9(2) condition | Notes |
+|---|---|---|---|---|
+| P1 | Measuring warehouse throughput to plan staffing | (f) legitimate interests | n/a | Achievable with team-level, not individual, data |
+| P2 | Individual productivity scoring and flagging | (f) legitimate interests `[to confirm: balancing test]` | n/a | Consent would not be freely given by employees |
+| P3 | Adjusting targets after sick leave | `[to confirm]` | `[to confirm: none identified]` | Health data; see Q3 |
+
+Legitimate interest pursued (P1, P2): running the warehouses efficiently and managing
+performance fairly.
+
+**Data inventory:**
+
+| Data category | Special category? | Data subjects | Source | Recipients and processors | Location / transfer | Retention |
+|---|---|---|---|---|---|---|
+| Employee ID, name, team, shift | no | Pickers (employees and agency workers) | HR system | Team leads; PickPulse vendor (processor) | EU (AWS Frankfurt); US support access | `[to confirm]` |
+| Scan events: item, timestamp, aisle location | no | Pickers | Handheld scanners | PickPulse vendor | As above | 2 years (stated) |
+| Idle time between scans | no | Pickers | Derived | Team leads; vendor | As above | 2 years (stated) |
+| Productivity score, rank, flag | no | Pickers | Derived | Team leads; HR on escalation | As above | `[to confirm]` |
+| Return-from-sick-leave dates | **yes, health** | Pickers | Absence calendar | PickPulse vendor | As above | `[to confirm]` |
+
+**Transfers:** US vendor support staff can access the data, which is a transfer to the US.
+Mechanism `[to confirm: vendor certified under the EU-US Data Privacy Framework, or SCCs
+with a transfer impact assessment]`. Agency workers' data may also be shared back with the
+agency `[to confirm]`.
+
+## 3. Necessity and proportionality (Art. 35(7)(b))
+
+| Question | Answer |
+|---|---|
+| Is each purpose necessary? | P1 yes, but team-level aggregates would meet it. P2 is the intrusive purpose; its necessity rests on the balancing test. |
+| Less intrusive alternative? | Aisle-level location and idle time are more detail than a daily score needs. Scoring on completed picks per hour, without location, would meet P2. |
+| Retention justified? | Two years of event-level scan data has no stated reason. The score could be kept; raw events could be aggregated after 30 days `[proposed]`. |
+| How are people told? | No notice described `[to confirm]`. |
+| Rights | No route described for a picker to see or contest their score `[to confirm]`. |
+| Decisions without human review (Art. 22)? | At risk. Team leads "mostly follow the flag"; if review is a rubber stamp, the flag is in effect an automated decision with a significant effect. |
+| Processor contract (Art. 28)? | `[to confirm]` |
+| Works council consulted (Art. 35(9))? | `[to confirm]`. In the Netherlands, works council involvement is also likely to be required under employment law; see Q6. |
+
+## 4. Risks to individuals (Art. 35(7)(c))
+
+| # | Risk to the person | Likelihood | Severity | Inherent |
+|---|---|---|---|---|
+| R1 | Pickers with a disability, a health condition or pregnancy are scored as low performers and face disciplinary steps for reasons unrelated to effort | probable | severe | **high** |
+| R2 | Flags are followed without real review, so pickers face performance action from an automated score they can't see or challenge | probable | significant | **high** |
+| R3 | Return-from-sick-leave data reveals health information to team leads and the vendor beyond what is needed | possible | significant | medium |
+| R4 | Continuous location and idle-time tracking creates pressure to skip breaks or toilet visits, harming health | possible | severe | **high** |
+| R5 | US support access exposes data to authorities without equivalent safeguards | remote | significant | low |
+| R6 | Two years of event-level data is reused for other purposes (for example, investigations) without people knowing | possible | significant | medium |
+
+## 5. Measures and residual risk (Art. 35(7)(d))
+
+| Risk | Measure | Owner | Status | Residual |
+|---|---|---|---|---|
+| R1 | Exclude time with an agreed adjustment from scoring; let pickers record reasonable adjustments with HR, not team leads | HR | proposed | high (unchanged until agreed) |
+| R2 | A flag starts a review only; the team lead must record a reason before any action; pickers see their own score and can contest it | Operations | proposed | high (unchanged until agreed) |
+| R3 | Send PickPulse a "target adjustment" flag with an end date, not sick-leave dates | HR / vendor | proposed | medium |
+| R4 | Remove idle-time and aisle-location from individual views; exclude breaks from scoring | Operations | proposed | high (unchanged until agreed) |
+| R5 | Confirm DPF certification or SCCs; restrict support access to on-request, logged sessions | Procurement | proposed | low |
+| R6 | Aggregate scan events after 30 days; purpose limitation in the notice and the vendor contract | DPO / vendor | proposed | medium |
+
+No measure is yet agreed, so residual risk equals inherent risk until the business commits.
+
+## 6. Prior consultation (Art. 36)
+
+R1, R2 and R4 are high with no agreed measures. **View: if those measures are not adopted,
+prior consultation with the supervisory authority looks needed.** If the measures for R1,
+R2 and R4 are agreed and bring each to medium or below, it does not look needed. For the
+DPO to confirm.
+
+## 7. Open questions for the DPO and the business
+
+| # | Question | Who can answer | Blocks |
+|---|---|---|---|
+| Q1 | Has the legitimate interests balancing test for P2 been documented? | DPO with Operations | §2 P2 |
+| Q2 | Is individual scoring needed at all, or would team-level throughput (P1) meet the business need? | Operations director | §3, R1, R2 |
+| Q3 | What Art. 9(2) condition, if any, covers using sick-leave data to adjust targets, or can P3 work without health data (R3 measure)? | DPO | §2 P3 |
+| Q4 | Is the vendor certified under the EU-US Data Privacy Framework, or are SCCs in place? | Procurement / vendor | §2 transfers |
+| Q5 | What are the retention periods for scores, flags and the employee profile? | HR / Operations | §2 inventory |
+| Q6 | Has the works council been consulted, and is its consent required? | HR / employment counsel | §3 |
+| Q7 | Is agency workers' data shared with the agencies, and on what basis? | HR | §2 inventory |
+
+## 8. DPO advice and sign-off
+
+| | |
+|---|---|
+| DPO advice | |
+| Advice followed? If not, why | |
+| Residual risks accepted by | |
+| Decision | |
+| Next review date or trigger | |
+
+---
+
+**Why this is a passing output:** risks are harms to pickers, not to Acme; each purpose has
+its own basis; health data is called out and lacks a condition, so it becomes Q3 instead of
+a guess; the US support access is treated as a transfer with the mechanism left to confirm;
+retention the user didn't give is `[to confirm]`; residual risk doesn't drop on proposed
+measures; and the sign-off block is blank.

skilldrop_cli/data/packs/grc/skills/dpia/manifest.json

@@ -0,0 +1,47 @@
+{
+  "name": "dpia",
+  "version": "0.1.0",
+  "description": "Draft a data protection impact assessment (DPIA) for one processing activity in the structure GDPR Article 35(7) requires — a systematic description of the processing and its purposes, necessity and proportionality, risks to the rights and freedoms of individuals, and the measures to address them — with a data inventory (categories, special category data, data subjects, sources, recipients, transfers outside the EEA, retention), the lawful basis per purpose, a likelihood × severity risk table scored for harm to people, residual risk, a view on prior consultation, and the open questions for the DPO. Use when the user needs a DPIA or PIA, is launching something that processes personal data in a new or risky way, or asks \"do we need a DPIA\", \"write the DPIA for…\", \"privacy impact assessment\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-threat-model",
+    "ai-usage-policy",
+    "risk-register",
+    "soc2-evidence-map",
+    "threat-model"
+  ],
+  "handoff": [
+    {
+      "to": "threat-model",
+      "when": "the processing runs on a new system whose security design hasn't been assessed",
+      "purpose": "Find the security threats to the system so the DPIA's measures section can cite them.",
+      "fallback": "If threat-model is absent, list the security measures the vendor or team states (access control, encryption, logging) in §5 and add a DPO question asking for a security review."
+    },
+    {
+      "to": "risk-register",
+      "when": "the DPIA leaves residual risks the business has accepted",
+      "purpose": "Track the accepted residual risks with an owner and review date alongside other organisational risks.",
+      "fallback": "If risk-register is absent, list each accepted residual risk with its owner and review trigger in §8."
+    }
+  ],
+  "tags": [
+    "dpia",
+    "gdpr",
+    "privacy",
+    "data-protection",
+    "grc",
+    "compliance"
+  ],
+  "model": {
+    "tier": "heavy",
+    "rationale": "Legal-structure judgment: screening, choosing a lawful basis per purpose, spotting inferred special category data and transfers, and scoring harm to individuals. Errors are costly and the input is usually incomplete."
+  }
+}