dataset-datasheet
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.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/dataset-datasheet && cp -r /tmp/dataset-datasheet/plugins/pm-ai/skills/dataset-datasheet ~/.claude/skills/dataset-datasheetSKILL.md
# 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.
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.