C15t
c15t/c15t
Work with c15t consent management docs, APIs, and integrations for Next.js, React, and JavaScript.
Classifies personal vs non-personal data per GDPR Art. An agent skill from mukul975/Privacy-Data-Protection-Skills.
Install Personal Data Test
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-test --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/privacy/personal-data-test .claude/skills/personal-data-test && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .claude/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-testType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-test --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/privacy/personal-data-test .agents/skills/personal-data-test && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .agents/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-test --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/privacy/personal-data-test .cursor/skills/personal-data-test && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .cursor/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/mukul975/Privacy-Data-Protection-Skills.git --path skills/privacy/personal-data-test--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-test --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/privacy/personal-data-test .gemini/skills/personal-data-test && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .gemini/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-testInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/privacy/personal-data-test .github/skills/personal-data-test && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .github/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install mukul975/Privacy-Data-Protection-Skills personal-data-test --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/mukul975/Privacy-Data-Protection-Skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/privacy/personal-data-test .opencode/skills/personal-data-test && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "personal-data-test" agent skill from https://github.com/mukul975/Privacy-Data-Protection-Skills/tree/main/skills/privacy/personal-data-test into .opencode/skills/personal-data-test/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "personal-data-test", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
personal-data-test- GitHub stars
- 295
- Token cost
- ~3.9k tokens
- SKILL.md length
- 1,689 words
- Files
- 5 (incl. scripts, references, assets)
- Skills in repo
- 278
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
Classifies personal vs non-personal data per GDPR Art. An agent skill from mukul975/Privacy-Data-Protection-Skills.
- Works in 8 steps: Is the Data About a Natural Person? → Can the Person Be Identified or Is the… → Anonymisation Verification → …
- Tasks that involve Privacy and GDPR
- SKILL.md covers Overview, Legal Foundation, The Breyer Ruling — CJEU… and Decision Tree for Personal…, plus 4 more sections
- Runs Python scripts from its folder
What it does
Personal Data Test is an agent skill from mukul975/Privacy-Data-Protection-Skills. Classifies personal vs non-personal data per GDPR Art. 4(1) definition test with decision tree for borderline cases. References Breyer v Germany CJEU C-582/14 dynamic IP ruling and WP29 Opinion 4/2007. Keywords: personal data, GDPR Art 4, data classification, Breyer ruling, identifiability test, PII.
Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including scripts, reference files and assets (for example `assets/template.md`, `references/standards.md` and `references/workflows.md`).
It sits in Legal & Compliance, covering Privacy and GDPR. The repository describes itself as: 282+ structured privacy & data protection skills for AI agents. GDPR, CCPA, EU AI Act, HIPAA, LGPD, PIPL, DPDP Act. The licence is Apache-2.0.
When your agent uses it
- Tasks that involve Privacy and GDPR
Example prompts
- “Use the personal-data-test skill to classify personal vs non-personal data per GDPR Art. An agent skill from mukul975/Privacy-Data-Protection-Skills”
- “/personal-data-test”
Requirements
- Python 3
Workflow steps
8 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit 9b2ef9e. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Ships 1 file in scripts/ (Python), which the agent can run.
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Personal Data Test loads about 3.9k tokens when it runs, and up to ~7.3k if it reads all its reference files. Until then it costs about 80 tokens; SKILL.md has 1,689 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
SKILL.md
The full file from mukul975/Privacy-Data-Protection-Skills at commit 9b2ef9e, republished under its Apache-2.0 licence (© mukul975). 1,689 words, ~3,915 tokens.
Download SKILL.mdSave it as
.claude/skills/personal-data-test/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.- name
- personal-data-test
- description
- Classifies personal vs non-personal data per GDPR Art. 4(1) definition test with decision tree for borderline cases. References Breyer v Germany CJEU C-582/14 dynamic IP ruling and WP29 Opinion 4/2007. Keywords: personal data, GDPR Art 4, data classification, Breyer ruling, identifiability test, PII.
- license
- Apache-2.0
- metadata.author
- mukul975
- metadata.version
- 1.0
- metadata.domain
- privacy
- metadata.subdomain
- data-classification
- metadata.tags
- personal-data, gdpr-art-4, classification, breyer-ruling, identifiability, pii
Personal Data Classification Test — GDPR Art. 4(1)
Overview
Article 4(1) of the GDPR defines personal data as "any information relating to an identified or identifiable natural person ('data subject')." This definition is deliberately broad and technology-neutral. The European Court of Justice in Breyer v Bundesrepublik Deutschland (C-582/14, 19 October 2016) confirmed that even dynamic IP addresses can constitute personal data when the controller has legal means to obtain additional information enabling identification. This skill provides a systematic decision framework for classifying data elements as personal, non-personal, or borderline requiring contextual assessment.
Legal Foundation
Art. 4(1) — Four Constituent Elements
Personal data exists when ALL four elements are satisfied:
| Element | Definition | Assessment Criteria |
|---|---|---|
| Any information | No restriction on nature, content, or format of information | Includes objective facts (age, blood type) and subjective assessments (credit rating, performance review). Covers all formats: text, image, audio, biometric, metadata, behavioural |
| Relating to | Information must have a content, purpose, or result link to the individual | Content link: information is about the person. Purpose link: information is used to evaluate or influence the person. Result link: processing has an impact on the person's rights or interests |
| Identified or identifiable | The person is or can be distinguished from all other persons | Identified: directly singled out. Identifiable: can be singled out by using additional data, taking into account all means reasonably likely to be used |
| Natural person | Living human being, not legal entities or deceased persons | Excludes companies, government bodies, associations. Member State law may extend protections to deceased persons (e.g., Italy extends to 20 years post-mortem) |
Recital 26 — "Reasonably Likely" Test for Identifiability
To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. The assessment must consider:
- All objective factors: cost of identification, time required, available technology at the time of processing, and technological developments anticipated during the retention period
- All means reasonably likely: not limited to means the controller currently possesses — includes means any third party might reasonably employ
- Dynamic assessment: what is not identifiable today may become identifiable as technology evolves or datasets are linked
The Breyer Ruling — CJEU C-582/14
Facts
Patrick Breyer challenged the German Federal Government's practice of storing dynamic IP addresses of visitors to government websites. Germany argued that dynamic IP addresses were not personal data because the website operator could not identify visitors without additional data held by the internet service provider (ISP).
Holding
The CJEU ruled that dynamic IP addresses constitute personal data for the website operator when:
- The operator has legal means available to obtain additional identifying information from a third party (the ISP)
- Identification does not require disproportionate effort in terms of time, cost, or labour
- The means are reasonably likely to be used — not merely theoretical
Key Legal Principles Established
- Relative approach to identifiability: Personal data status is assessed relative to each controller's circumstances, not in the abstract
- Legal means suffice: The controller need not currently possess the identifying data; having legal channels to obtain it is sufficient
- Third-party knowledge counts: Information held by third parties must be considered if the controller has lawful means of access
- Broad interpretation: The CJEU confirmed the GDPR's (then Directive 95/46/EC's) intent to apply broadly to protect fundamental rights
Practical Impact
After Breyer, the following are presumptively personal data for most controllers:
- Dynamic and static IP addresses
- Device fingerprints and browser fingerprints
- Cookie identifiers and advertising IDs
- MAC addresses when combined with network access logs
- Pseudonymised datasets where re-identification keys exist or are obtainable
Decision Tree for Personal Data Classification
Stage 1: Is the Data About a Natural Person?
Data Element
│
├── About a living natural person? ──► YES → Go to Stage 2
│
├── About a deceased person? ──► Check Member State law (may still be protected)
│
├── About a legal entity only? ──► NOT personal data under GDPR
│ (but may contain personal data of individuals within,
│ e.g., sole trader name = personal data)
│
└── About an anonymous aggregate? ──► Go to Stage 3 (verify truly anonymous)Stage 2: Can the Person Be Identified or Is the Person Identifiable?
Data relates to a natural person
│
├── Person is DIRECTLY identified?
│ (name, photograph, unique ID number)
│ ──► PERSONAL DATA
│
├── Person is INDIRECTLY identifiable?
│ (combination of data points enables singling out)
│ ──► Apply Recital 26 "reasonably likely" test → Stage 2a
│
└── Person cannot be identified by any means reasonably likely?
──► NOT personal data (but document the assessment)Stage 2a: Recital 26 Reasonably Likely Assessment
Indirect identifiers present
│
├── Does the controller hold additional data enabling identification?
│ ──► YES → PERSONAL DATA
│
├── Does a third party hold such data, and does the controller
│ have legal means to access it? (Breyer test)
│ ──► YES → PERSONAL DATA
│
├── Could publicly available data be combined to identify?
│ (social media, public registers, news articles)
│ ──► YES → PERSONAL DATA
│
├── Is re-identification feasible considering:
│ - Cost vs. value of identification
│ - Time required vs. retention period
│ - Current and foreseeable technology
│ ──► YES → PERSONAL DATA
│
└── Identification requires disproportionate effort with no
reasonable motivation?
──► NOT personal data (document reasoning)Stage 3: Anonymisation Verification
Data claimed to be anonymous/aggregated
│
├── Can any individual be singled out from the dataset?
│ ──► YES → PERSONAL DATA (pseudonymised, not anonymised)
│
├── Can records be linked to form a profile of an individual?
│ ──► YES → PERSONAL DATA
│
├── Can information be inferred about a specific individual?
│ ──► YES → PERSONAL DATA
│
└── Passes all three tests (singling out, linkability, inference)?
──► Anonymised data — NOT personal data
(Apply WP29 Opinion 05/2014 framework)Classification Categories with Examples
Category A: Clear Personal Data (Always Personal)
| Data Element | Reason |
|---|---|
| Full name | Direct identifier |
| National ID number (SSN, Aadhaar, BSN) | Unique direct identifier |
| Email address (personal) | Directly identifies in most contexts |
| Photograph of a face | Direct visual identifier (also biometric if processed for identification) |
| Biometric data (fingerprint, iris scan) | Unique to individual, Art. 9 special category when used for identification |
| Genetic data | Unique biological identifier, Art. 9 special category |
| Health records with patient name | Direct identifier plus Art. 9 special category |
| Home address with name | Direct identifier with location |
Category B: Contextually Personal Data (Requires Assessment)
| Data Element | When Personal | When Not Personal |
|---|---|---|
| Dynamic IP address | When controller has legal means to obtain subscriber info from ISP (Breyer) | When controller has no means and no motivation to identify (rare) |
| Cookie identifier | When linked to browsing profile that enables singling out | When session-only cookie with no profile building |
| Device fingerprint | When used to track across sites/sessions | When used only for aggregate device statistics with k-anonymity |
| Employee ID number | When linked to HR records by same controller | When used in anonymised survey with no re-identification key |
| Location data (GPS coordinates) | When tracking individual movement patterns | When aggregated to postcode-level with >1000 individuals per cell |
| Purchase history | When linked to customer account | When stripped of all identifiers and aggregated by product category |
| Vehicle registration number | When plate-to-owner lookup is legally available | Not applicable — plate lookup is available in most jurisdictions, so nearly always personal |
Category C: Typically Not Personal Data
| Data Element | Condition for Non-Personal Status |
|---|---|
| Weather data | General environmental data not relating to individuals |
| Stock prices | Corporate financial data |
| Machine sensor readings | Equipment telemetry with no operator identification |
| Aggregated census statistics | Published statistical tables with adequate anonymisation |
| Chemical compound properties | Scientific data about substances |
| Company financial statements | Legal entity data (but may contain director names) |
Borderline Cases — Detailed Analysis
Case 1: Pseudonymised Data
Pseudonymised data remains personal data under GDPR (Recital 26, Art. 4(5)). The existence of a re-identification key — even if held by a separate entity — means the data relates to an identifiable person. Pseudonymisation is a security measure, not an anonymisation technique.
Vanguard Financial Services Application: Customer transaction records where account numbers are replaced with random tokens. The mapping table is held by a separate internal department with access controls. These remain personal data because:
- Vanguard holds the re-identification key internally
- Re-identification requires minimal effort (database lookup)
- The data was processed for purposes relating to specific customers
Show full SKILL.md (635 more words)Show less
Case 2: Behavioural Profiles Without Direct Identifiers
A profile built from browsing behaviour, purchase patterns, and location data — even without a name or email — constitutes personal data when the profile enables singling out the individual. The Article 29 Working Party in Opinion 4/2007 on the concept of personal data confirmed that "a profile can in itself be sufficient to identify a specific user."
Case 3: Encrypted Data
Encrypted personal data remains personal data for the controller who holds the decryption key. For a third party without the key and no reasonable means to obtain it, the encrypted data may not constitute personal data (applying the Breyer relative approach). However, this assessment must account for future cryptanalytic capabilities.
WP29 Opinion 4/2007 — Key Principles
The Article 29 Working Party Opinion 4/2007 on the concept of personal data established foundational interpretive guidance:
- Content element: Information "about" a person exists when the content concerns that individual, regardless of purpose or result
- Purpose element: Data is "about" a person when it is used or likely to be used to evaluate, treat, or influence that person
- Result element: Data is "about" a person when processing is likely to have an impact on that person's rights or interests
- Any one element suffices: Data need only satisfy the content, purpose, OR result element to "relate to" a person
Implementation Procedure for Vanguard Financial Services
Step 1: Data Element Inventory
For each system, catalogue every data element collected, stored, or processed. Record:
- Field name and data type
- Source of data (collected from data subject, derived, inferred, received from third party)
- Sample values (redacted as needed)
- Current classification if any
Step 2: Apply the Four-Element Test
For each data element, document the assessment against Art. 4(1):
- Is this any information? (Almost always yes)
- Does it relate to a natural person? (Content, purpose, or result link)
- Is the person identified or identifiable? (Direct or indirect, applying Breyer)
- Is the person a living natural person?
Step 3: Borderline Assessment
For elements not clearly personal or non-personal:
- Apply the Recital 26 reasonably likely test
- Consider the Breyer third-party knowledge doctrine
- Document the reasoning and conclusion
- Assign to a review schedule (reassess annually or when technology/data partnerships change)
Step 4: Classification Tagging
Apply classification labels:
PERSONAL_DIRECT: Directly identifies a natural personPERSONAL_INDIRECT: Indirectly identifies through combination or third-party dataSPECIAL_CATEGORY: Art. 9 special category personal dataPSEUDONYMISED: Personal data with re-identification key separatedANONYMISED: Verified anonymous data (not personal data)NON_PERSONAL: Not personal data under any reasonable assessmentBORDERLINE_REVIEW: Requires periodic reassessment
Step 5: Documentation and Governance
- Record all classification decisions in the data inventory
- Link each personal data element to its Art. 6 lawful basis
- Link Art. 9 special category data to its Art. 9(2) processing condition
- Schedule annual review of borderline classifications
- Trigger reclassification when new data partnerships, technologies, or regulatory guidance emerge
Enforcement Precedents
- Breyer v Bundesrepublik Deutschland (CJEU C-582/14, 2016): Dynamic IP addresses are personal data when legal means to identify exist — established the relative identifiability standard
- Nowak v Data Protection Commissioner (CJEU C-434/16, 2017): Examination answers and examiner's corrections are personal data of the candidate — applied the broad "relating to" test
- YS v Minister voor Immigratie (CJEU C-141/12, 2014): Legal analysis in an immigration decision document is personal data of the applicant — the "result" element of the relating-to test
- Scarlet Extended SA v SABAM (CJEU C-70/10, 2011): IP addresses collected in the context of monitoring internet traffic constitute personal data
Integration Points
- Art. 9 Special Categories: Personal data classified as special category requires additional processing conditions — see
special-category-dataskill - Art. 30 Records of Processing: Classification feeds directly into the categories of personal data field in RoPA
- Art. 35 DPIA: High-risk personal data classifications trigger DPIA requirements
- Art. 25 Data Protection by Design: Classification determines the level of technical protection required
© mukul975, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 4 other files (scripts, references, assets) in skills/privacy/personal-data-test of mukul975/Privacy-Data-Protection-Skills.
- SKILL.md
- assets/template.md
- references/standards.md
- references/workflows.md
- scripts/process.py
Open the folder on GitHubat commit 9b2ef9e
Compare with similar skills
Personal Data Test next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Personal Data Test this skillmukul975/Privacy-Data-Protection-Skills | 295 | — | ~3.9k | Automated safety check: Pass | Apache-2.0 | |
| C15tc15t/c15t | 1.9k | 1 repos | ~1.6k | Automated safety check: Pass | Apache-2.0 | |
| HIPAA Safe Harbor Coverage Auditmaziyarpanahi/openmed | 5.5k | — | ~1.7k | Automated safety check: Pass | Apache-2.0 | |
| Korean Privacy Termskimlawtech/korean-privacy-terms | 586 | — | ~2.9k | Automated safety check: Pass | Apache-2.0 | |
| Gdpr ComplianceSushegaad/Claude-Skills-Governance-Risk-and-Compliance | 942 | 1 repos | ~3.9k | Automated safety check: Pass | MIT | |
| Hipaa ComplianceSushegaad/Claude-Skills-Governance-Risk-and-Compliance | 942 | 1 repos | ~2.3k | Automated safety check: Pass | MIT |
Similar skills
HIPAA Safe Harbor Coverage Audit
maziyarpanahi/openmed
Checks OpenMed de-identified clinical text against the 18 HIPAA Safe Harbor identifier categories and reports gaps and residual re-identification risk.
Korean Privacy Terms
kimlawtech/korean-privacy-terms
처리방침·이용약관 자동 생성 스킬 패키지 (v4.0). An agent skill from kimlawtech/korean-privacy-terms.
Gdpr Compliance
Sushegaad/Claude-Skills-Governance-Risk-and-Compliance
Expert GDPR compliance assistant covering all four core workflows: (1) auditing code and systems for GDPR violations, (2) drafting GDPR-compliant documents such as privacy policies, Data Processing…
Hipaa Compliance
Sushegaad/Claude-Skills-Governance-Risk-and-Compliance
Expert HIPAA compliance assistant for healthcare and software contexts.
Pii Contract Analyze
gregmos/PII-Shield
Universal legal document processor with PII anonymization. An agent skill from gregmos/PII-Shield.
More from mukul975/Privacy-Data-Protection-Skills
All 278 skills in this repoAge Gating Services
mukul975/Privacy-Data-Protection-Skills
Implements age-gating mechanisms for online services to restrict access based on user age.
AI Data Retention
mukul975/Privacy-Data-Protection-Skills
Manages AI model retention and machine unlearning requirements.
Dpia Mitigation Plan
mukul975/Privacy-Data-Protection-Skills
Structures risk mitigation planning and residual risk tracking for Data Protection Impact Assessments under GDPR Article 35(7)(d).
Gdpr Accountability
mukul975/Privacy-Data-Protection-Skills
Guides implementation of the GDPR accountability principle under Articles 5(2) and 24, including documentation requirements for policies, DPIAs, RoPA, training records, and breach logs.
Pia Threshold Screening
mukul975/Privacy-Data-Protection-Skills
Conducts pre-DPIA threshold screening to determine whether a full Data Protection Impact Assessment is required under GDPR Article 35.
Retention Schedule
mukul975/Privacy-Data-Protection-Skills
Designs and implements data retention schedules compliant with GDPR Article 5(1)(e) storage limitation principle.
Related
Categories
Questions about Personal Data Test
What does Personal Data Test do?
Classifies personal vs non-personal data per GDPR Art. An agent skill from mukul975/Privacy-Data-Protection-Skills. Personal Data Test is an agent skill from mukul975/Privacy-Data-Protection-Skills. Classifies personal vs non-personal data per GDPR Art.
When should I use Personal Data Test?
Personal Data Test fits situations like: tasks that involve Privacy and GDPR.
How do I install Personal Data Test in Claude Code?
Run `npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a claude-code`. Or copy the skill folder (skills/privacy/personal-data-test in mukul975/Privacy-Data-Protection-Skills) into .claude/skills/personal-data-test in your project. Claude Code loads it when a task matches its description.
How do I install Personal Data Test in Codex?
Run `npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a codex`. Or copy the skill folder (skills/privacy/personal-data-test in mukul975/Privacy-Data-Protection-Skills) into .agents/skills/personal-data-test in your project. Codex loads it when a task matches its description.
Can I use Personal Data Test in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mukul975/Privacy-Data-Protection-Skills --skill personal-data-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/personal-data-test, .gemini/skills/personal-data-test, .github/skills/personal-data-test and .opencode/skills/personal-data-test in your project.
What does Personal Data Test need to run?
Going by SKILL.md and its folder, Personal Data Test needs Python for the scripts in its folder. Our summary lists: Python 3.
Does Personal Data Test access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Personal Data Test safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
What licence does Personal Data Test use?
Personal Data Test is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Personal Data Test use?
About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 3.4k tokens, read only when the agent opens those files.
What are the alternatives to Personal Data Test?
Skills that share tags, products or a category with Personal Data Test: C15t (c15t/c15t, 1.9k stars), HIPAA Safe Harbor Coverage Audit (maziyarpanahi/openmed, 5.5k stars), Korean Privacy Terms (kimlawtech/korean-privacy-terms, 586 stars) and Gdpr Compliance (Sushegaad/Claude-Skills-Governance-Risk-and-Compliance, 942 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Personal Data Test?
mukul975 (a GitHub user) maintains it in mukul975/Privacy-Data-Protection-Skills, which has 295 GitHub stars. The repository holds 278 skills in this directory. The repository was last updated on March 16, 2026.
Source: mukul975/Privacy-Data-Protection-Skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.