Document a dataset so others know what it is, how it was made, and when not to use it. Use when asked to write a datasheet for a dataset, document training/e...
---
name: dataset-datasheet
description: "Document a dataset so others know what it is, how it was made, and when not to use it. Use when asked to write a datasheet for a dataset, document training/eval data, or assess whether a dataset is fit for a use. Produces a datasheet โ motivation, composition, collection process, preprocessing, recommended uses & limits, distribution, and maintenance."
homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/dataset-datasheet.html
metadata:
{
"openclaw": { "emoji": "๐ค" }
}
---
# Dataset Datasheet Skill
Models inherit the flaws of their data, and most data debt is invisible because nobody wrote down where
the data came from. A datasheet is that record: how the dataset was collected, what's in it, what's
missing, and what it should *not* be used for. It's the difference between a reusable asset and a liability.
## Required Inputs
Ask for these only if they aren't already provided:
- **Dataset name, version, owner** and what it's used for today.
- **Motivation** โ why it was created and for what task.
- **Composition** โ what an instance is, how many, fields/labels, and time range.
- **Collection** โ sources, method (scraped, logged, purchased, annotated), and consent/licensing basis.
- **Known issues** โ gaps, imbalances, label noise, sensitive attributes, duplicates.
## Output Format
### Datasheet: [dataset] v[version]
**Owner:** [team] ยท **Created:** [date] ยท **License:** [license]
**1. Motivation** โ why this dataset exists, the task it serves, and who funded/created it.
**2. Composition**
- What a single instance represents; total count; the schema (fields, label definitions).
- Class/label balance and key distributions (and notable skews).
- **Sensitive attributes** present (directly or by proxy), and whether individuals are identifiable.
- Known missing data, duplicates, or noise.
**3. Collection process** โ sources, mechanism (scrape/log/survey/annotation), time window, sampling strategy, and the **legal/consent basis** (license, ToS, opt-in).
**4. Preprocessing / labelling** โ cleaning, dedup, filtering, and how labels were produced (who annotated, guidelines, inter-annotator agreement).
**5. Recommended uses & limits**
- **Appropriate uses:** tasks this data supports well.
- **Do not use for:** tasks where its biases/gaps would cause harm or invalid results.
**6. Distribution & access** โ who can use it, how it's shared, and tenancy/PII handling.
**7. Maintenance** โ owner, update cadence, versioning, and how errors get reported and fixed.
## Quality Checks
- [ ] The collection method and **legal/consent basis** are stated โ not assumed
- [ ] Class balance and key distribution skews are quantified, not hand-waved
- [ ] Sensitive attributes (and proxies for them) are identified explicitly
- [ ] "Do not use for" lists concrete tasks where the data would mislead
- [ ] Label provenance is documented (who labelled, with what guidelines, and agreement level)
- [ ] An owner and update/error-reporting process are named
## Anti-Patterns
- [ ] Do not describe only the happy-path contents โ the gaps, skews, and noise are what cause model failures
- [ ] Do not omit the consent/licensing basis โ "we scraped it" is a legal and ethical liability if undocumented
- [ ] Do not ignore proxy variables โ removing race/gender columns doesn't remove the bias if zip code or name encodes it
- [ ] Do not present label quality as perfect โ state who labelled it and the agreement rate, or note it's unmeasured
- [ ] Do not leave the dataset ownerless โ an unmaintained dataset silently rots as the world changes
## Based On
Datasheets for Datasets (Gebru et al., 2018) and data-documentation practice in responsible-AI reviews.
don't have the plugin yet? install it then click "run inline in claude" again.