CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/pii-masking-pipeline-builder

Use when non-production environments need masked production data. Classifies each field against GDPR, CCPA, NIST and HIPAA PII categories, picks a masking operator, decides pseudonymization vs anonymization, emits a Presidio, Faker and Synthea config and blocks promotion if a re-scan finds PII.

Quality

92%

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

Overview
Quality
Evals
Security
Files

Quality

Content

88%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 high-quality, highly actionable skill body: concrete tables, a decision tree, executable YAML specs, and an unusually strong adversarial verification pass with explicit block conditions and feedback loops. The main improvement levers are trimming the overlap between the Step 6 and Step 7 YAML examples and flattening the two-level 'deep reference' chain.

Suggestions

Condense or merge the Step 7 worked example with the Step 6 spec template - the two ~45-line YAML blocks overlap heavily and the worked example could be a short diff-style annotation instead.

Flatten the reference hierarchy: privacy-models.md and regime-catalogs.md are 'deep references behind' masking-techniques.md and pii-categories.md respectively; promoting both to first-level peers in the References section (or linking them directly at point of use) would remove the second-level nesting.

Trim minor parenthetical asides (e.g. 'e.g., a user-typed comment that contains an email') that restate what the surrounding rule already implies.

DimensionReasoningScore

Conciseness

Dense and operational with essentially no explanation of concepts Claude already knows; detail catalogs are pushed to references. Minor redundancy keeps it from the top anchor: the Step 7 worked example substantially repeats the Step 6 YAML shape (~90 lines of YAML across the two blocks) and a few parenthetical asides could be trimmed.

4 / 5

Actionability

Fully executable guidance throughout: a copy-paste-ready YAML spec with concrete parameters (score_threshold: 0.45, keep_chars: 3, salt_ref: vault://...), an executable audit command (shuf -n 1000 masked-users.csv > sample.csv), a 6-branch operator decision tree, and a worked nightly-refresh example covering the common case end-to-end.

5 / 5

Workflow Clarity

Steps 1-7 are clearly sequenced and finish with an adversarial verification pass containing a 5-item audit checklist, explicit BLOCK / PASS-WITH-CAVEATS / PASS verdict rules, and feedback loops ('Re-audit on every pipeline-spec change'). Because this batch workflow includes explicit validation and refusal conditions, the destructive/batch cap at 3 does not apply.

5 / 5

Progressive Disclosure

All five referenced files exist and are directly linked with clear signaling, and bulky catalogs (regime enumerations, privacy models, Faker mechanics) are correctly split out of SKILL.md. Falls short of the top anchor because privacy-models.md and regime-catalogs.md are explicitly framed as second-level 'deep reference behind' other reference files, and the ~330-line body inlines a worked example that could live in a reference.

4 / 5

Total

18

/

20

Passed

Description

92%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.

A strong description: third-person voice, explicit 'Use when' trigger, and a comprehensive list of concrete pipeline actions from classification through promotion blocking. The only gap is modest synonym coverage for trigger terms users might naturally say.

Suggestions

Add common user phrasings as trigger terms, e.g. 'de-identify' or 'anonymize production data for staging/dev', so the description fires on the words users actually say.

Consider naming the output artifact (a masking-pipeline YAML spec) in the description so users searching for 'pipeline' or 'spec' land on this skill.

DimensionReasoningScore

Specificity

Lists five concrete, distinct actions covering the full pipeline lifecycle ("Classifies each field against GDPR, CCPA, NIST and HIPAA PII categories, picks a masking operator, decides pseudonymization vs anonymization, emits a Presidio, Faker and Synthea config and blocks promotion if a re-scan finds PII"). Coverage is comprehensive rather than having minor gaps, so it matches the top anchor, not the 4 anchor.

5 / 5

Completeness

Explicitly answers both questions: an explicit "Use when non-production environments need masked production data" trigger clause plus a complete third-person action list for the "what". The when-clause names a concrete scenario rather than a generic domain, matching the 5 anchor over the 4 anchor's vaguer 'when'.

5 / 5

Trigger Term Quality

Natural phrases like "masked production data", "PII", "GDPR, CCPA, NIST and HIPAA", and "Presidio" are present, but common user synonyms such as "de-identify", "anonymize prod data", or "staging/dev refresh" are missing. Good coverage but not the comprehensive synonym coverage of the 5 anchor.

4 / 5

Distinctiveness Conflict Risk

Clear niche (masking production snapshots for non-production use) with distinct regulatory- and tool-based triggers (GDPR/CCPA/NIST/HIPAA, Presidio, Faker, Synthea). Minimal conflict risk even against adjacent skills such as a general PII-detection skill, since the scenario trigger cleanly separates masking pipelines from detection.

5 / 5

Total

19

/

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.

Reviewed

On this page