data-minimisation

Use when reviewing form components, API payloads, or client-side storage to identify fields that are collected but not consumed by a stated feature.

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/data-minimisation/SKILL.md

Quality

Content

57%

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

The skill is well-organized with clean progressive disclosure — a lean overview deferring details to a single real reference file. It is held back by motivational/GDPR padding Claude doesn't need, description-level rather than worked-example actionability, and an audit-then-fix workflow that lacks explicit verification checkpoints.

Suggestions

Trim or remove the introductory GDPR/breach-impact paragraph and the redundant motivation in "Explain"; assume Claude already knows data-minimisation rationale.

Add a verification step to the workflow (e.g. "After remediation, re-scan analytics and logging payloads to confirm no raw email/name/phone values remain") to close the feedback loop.

Include one concrete worked example — a sample form field set with which fields to drop vs. pseudonymise — to move actionability from descriptive to directly applicable.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean, but the opening paragraph ("Collecting more data than necessary increases the blast radius of a breach, exposes your organisation to regulatory fines, and erodes user trust. GDPR Article 5(1)(c) makes data minimisation a legal obligation...") explains GDPR/breach-impact concepts Claude already knows, and the "Explain" section partly repeats that motivation.	2 / 3
Actionability	Guidance names concrete targets and remediation ("Replace raw personal identifiers in analytics and logs with pseudonymous IDs and define a retention window"), but as an instruction-only skill it stops at description-level direction with no worked example of an audit finding or a concrete anonymisation technique, leaving key implementation details implied.	2 / 3
Workflow Clarity	The Check → Fix → Explain → Code Review sections imply a loose sequence, but there are no validation/verification checkpoints (e.g. confirming no raw PII remains in analytics payloads after remediation), which caps the level at 2 per the destructive/batch-operations guideline.	2 / 3
Progressive Disclosure	The body is a concise, well-sectioned overview (Quick Reference, Check, Fix, Explain, Code Review) with a clearly signaled one-level-deep pointer to the real bundle file `references/rule.md` for full implementation details, matching the level-3 anchor.	3 / 3
	Total	9 / 12 Passed

Description

75%

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

The description is well-structured with an explicit trigger clause that answers both what and when, and it carves out a distinctive privacy niche. Its main weakness is trigger-term naturalness — it leans on specialized phrasing and omits the plain-language terms (PII, personal data, privacy) a user would most likely say.

Suggestions

Add the natural-language terms users actually say — e.g. extend the trigger to mention "personal data", "PII", or "collecting too much user data" — so it matches how the need is expressed in practice.

Consider framing the action as multiple concrete verbs (e.g. "audit, flag, and remove or anonymise fields") to reach the level-3 specificity anchor.

Dimension	Reasoning	Score
Specificity	Names concrete targets ("form components, API payloads, or client-side storage") and a specific action ("identify fields that are collected but not consumed by a stated feature"), but it is a single action verb rather than the multiple distinct concrete actions the level-3 anchor requires.	2 / 3
Completeness	Explicitly answers both: the "what" ("identify fields that are collected but not consumed by a stated feature") and the "when" via an explicit "Use when reviewing..." trigger clause, matching the level-3 anchor.	3 / 3
Trigger Term Quality	"form components, API payloads, client-side storage" are reasonably natural developer terms, but the discriminating phrase "collected but not consumed by a stated feature" is jargony and common variations a user might actually say ("personal data", "PII", "privacy", "collecting too much data") are missing.	2 / 3
Distinctiveness Conflict Risk	The "collected but not consumed by a stated feature" framing carves out a distinct data-minimisation niche with a trigger phrase unlikely to fire for unrelated skills, satisfying the level-3 anchor.	3 / 3
	Total	10 / 12 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/data-minimisation/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours ago

Table of Contents

Discovery Implementation Validation

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.