CtrlK
BlogDocsLog inGet started
Tessl Logo

pseudonymizing-for-gdpr

Apply GDPR-grade pseudonymization to clinical or personal text with OpenMed, keeping a separately-held re-linkage key so the data can be controlled-re-linked later. Use when the user must process EU personal/health data under GDPR, asks for pseudonymization vs anonymization, needs Art. 4(5) / Art. 9 / Recital 26 alignment, wants a reversible mapping/key vault held apart from the data, or needs controlled re-linkage. Covers openmed.deidentify(policy="gdpr_pseudonymization", keep_mapping=True), storing the mapping in a separate key vault, reidentify() for authorized re-linkage, and retention. Pairs after extracting-pii-entities and configuring-privacy-policies.

74

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong, highly actionable body: executable code with real parameters, a well-sequenced five-step workflow, and thoughtful edge cases that show domain maturity (reproducibility trade-offs, quasi-identifiers, lawful basis). The main weaknesses are mild over-explanation of GDPR law Claude already knows, validation checkpoints that are referenced rather than embedded in the workflow, and no use of reference files to keep the main document lean.

Suggestions

Trim the two opening paragraphs to a two-sentence operational statement of the Art. 4(5) distinction (pseudonymized data is still personal data; key must be kept separately) and move the verbatim legal exposition to the Standards & references section or a reference file — Claude already knows the GDPR definitions.

Embed a validation step directly in the Workflow (e.g. step 2.5: scan deidentified_text with auditing-deid-leakage before it leaves the boundary) and add the failure path: what to do when the scan finds residual identifiers, instead of leaving that guidance only in the hand-off section.

Move the Edge cases & gotchas and Standards & references sections into a single one-level-deep reference file (e.g. references/edge-cases.md) to reduce SKILL.md's token footprint while keeping the quick start and workflow inline.

DimensionReasoningScore

Conciseness

The body is mostly efficient (executable quick start, terse numbered workflow), but the two-paragraph GDPR Art. 4(5)/Recital 26 definitional exposition re-teaches legal concepts Claude already knows, and some gotcha prose ('The mapping is the crown jewel') could be tightened. This matches anchor 4 ('minor instances of over-explanation that could be trimmed') rather than anchor 5's every-token-earns-its-place bar.

4 / 5

Actionability

The quick start is copy-paste-ready with all decisive parameters shown (method="replace", policy="gdpr_pseudonymization", keep_mapping=True, consistent=True, seed=), and the workflow names exact attributes and calls (result.deidentified_text, result.mapping, openmed.reidentify(deidentified_text, mapping)). Matches anchor 5's fully-executable, common-cases-covered profile.

5 / 5

Workflow Clarity

Five clearly sequenced steps with the critical split-data-from-key action at step 2 and authorization gating at step 4. Validation guidance exists (audit via auditing-deid-leakage, verify the anonymization claim via reviewing-reidentification-risk) but there is no feedback loop for the failure case (what to do when the leakage scan finds residual identifiers) and checkpoints sit partly in the hand-off section rather than inline. Matches anchor 4, not anchor 5; the destructive/batch cap does not apply since this is a transform, not a batch or destructive operation.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), so structure rests on section organization: clear headers (When to use, Quick start, Workflow, Hand-off, Edge cases, Standards) with no nested references. However, at ~130 lines the edge-cases and standards/references sections are content that could be split into one-level-deep reference files to keep SKILL.md lean, and no external references are provided at all — matching anchor 4 rather than anchor 5's well-signaled reference structure.

4 / 5

Total

17

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: it states concrete capabilities with the exact API calls and parameters, provides an explicit 'Use when' clause with multiple natural trigger phrases, and carves out a distinct niche that is unlikely to fire for sibling de-identification skills. Verbosity does not mask substance here — every clause carries trigger or capability information.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions including the exact API surface: "Apply GDPR-grade pseudonymization... keeping a separately-held re-linkage key" and "Covers openmed.deidentify(policy=\"gdpr_pseudonymization\", keep_mapping=True), storing the mapping in a separate key vault, reidentify() for authorized re-linkage, and retention". Coverage is comprehensive with no gaps, matching the anchor-5 example rather than anchor 4.

5 / 5

Completeness

Both questions are explicitly answered: the 'what' ("Apply GDPR-grade pseudonymization... Covers openmed.deidentify(...)") and an explicit "Use when..." clause enumerating five concrete trigger scenarios. This matches anchor 5's pattern of clearly answering both with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural user-facing phrases are comprehensively covered: "pseudonymization vs anonymization", "process EU personal/health data under GDPR", "reversible mapping/key vault held apart from the data", "controlled re-linkage", plus domain-specific synonyms (Art. 4(5), Art. 9, Recital 26). This matches anchor 5's comprehensive synonym coverage rather than anchor 4's 'a few natural terms missing'.

5 / 5

Distinctiveness Conflict Risk

The skill occupies a clear niche (GDPR pseudonymization with OpenMed, reversible by design) and is explicitly distinguished from anonymization ("irreversible anonymization for open release" is excluded in the body). Naming sibling skills (extracting-pii-entities, configuring-privacy-policies) further reduces overlap risk, matching anchor 5's minimal-conflict profile.

5 / 5

Total

20

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
maziyarpanahi/openmed
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.