Data Management Plan

/data-management-plan — Funder-Compliant DMP Generator

Produce a Data Management Plan ready to paste into a funder portal. This skill writes the prose and structure; it does not submit anywhere. It is a composition skill — it folds the disclosure-avoidance / IRB rules from .claude/rules/confidential-data.md and the environment + replication-package plan from /capture-environment and /replication-package into a single funder-shaped document.

When to use

• Writing a grant proposal. Every NSF, NIH, ERC, and Horizon Europe proposal needs a DMP (NSF), DMS Plan (NIH 2023 policy), or Data Management Plan (ERC/Horizon). /grant-proposal follows this skill for that section, through an Agent that reads this SKILL.md (the skill is user-invoked only, so it is followed, not invoked).
• Before data collection on a funded project. The plan is a commitment you make at award time and report against at renewal.
• When restricted or human-subjects data is involved. The access/sharing and preservation sections change materially — see Phase 2.

When NOT to use

• For a clinical-trial data-sharing statement governed by ICMJE / ClinicalTrials.gov — use the trial sponsor's template.
• As a substitute for IRB protocol text — the DMP references IRB constraints; it is not the protocol itself.

Inputs

• $0 --funder nsf|nih|erc|horizon — target funder profile. If omitted, Phase 0 detects it from --input or asks once.
• --input <path> — a research spec (/interview-me output under quality_reports/specs/), a grant draft, or a passport-adjacent description. The skill extracts data types, sample, and identification strategy from it.
• --no-verify — skip the Phase 4 citation/standard post-flight (inherited from /preregister).

Workflow

Phase 0 — Detect funder + data sensitivity

1. Resolve the funder (--funder, else infer from --input, else ask once). Load its section schema:

   Funder	Plan name	Required sections (abridged)
   NSF	Data Management Plan (2 pp max)	data types · standards · access/sharing · re-use/redistribution · archiving
   NIH	DMS Plan (2023 policy)	data type · tools/software · standards · preservation/access/timelines · access/distribution + reuse · oversight
   ERC	DMP (Horizon Europe Annex)	FAIR per dataset · data summary · making data FAIR · resource allocation · security · ethics
   Horizon Europe	DMP (DMP template)	same FAIR-first structure as ERC; open by default, "as open as possible, as closed as necessary"

2. Classify the data on three axes (drives Phases 2–3):

   • Public (open survey, scraped public records, simulated) — minimal restrictions.
   • Restricted (admin/tax/Census, proprietary, licensed under DUA) — access procedures dominate.
   • Human-subjects (PII, biospecimen-linked, survey with identifiers) — IRB + disclosure avoidance dominate.

   If the data is restricted or human-subjects, set sensitive = true and run Phase 2. If it is purely public, Phase 2 is a short paragraph.

Phase 1 — Scaffold sections from the funder profile

Generate the six house sections, mapped onto the funder's required headings:

1. Data description & types — what data, source, volume, formats produced. Be specific: panel/admin microdata, RCT outcomes, event-study event files, replication intermediate .rds/.dta/.parquet.
2. Formats & metadata standards — open/non-proprietary formats where possible (.csv/.parquet over .dta; codebooks; DDI / Dublin Core / domain schema). Name the standard, don't say "appropriate metadata".
3. Storage & backup — during the project: encrypted institutional storage, 3-2-1 backup, version control for code (not raw restricted data in git).
4. Access & sharing — who can access, when, under what terms. For restricted data this is the restricted-data access procedure (see Phase 2).
5. Preservation & archiving — a named repository with a persistent identifier (see Phase 3).
6. Roles & responsibilities — PI as data steward, data manager, institutional support, succession plan.

For any required field the input does not supply, write [CLARIFY: <specific question>] rather than fabricating — same convention as /preregister.

Phase 2 — Fold in disclosure-avoidance + IRB constraints (only if sensitive = true)

Pull the relevant rules from .claude/rules/confidential-data.md and weave them into the access & sharing and preservation sections:

• Restricted data → describe the access path, not the data. State the data provider, the DUA/restricted-use agreement, and how a replicator obtains access (e.g., FSRDC application, openICPSR restricted-access tier, provider application). The data itself is not deposited; the path to it is.
• Human-subjects → IRB + minimization. Reference the IRB protocol number (or [CLARIFY:]), the consent terms governing sharing, and the de-identification plan. Shared outputs are de-identified per the consent.
• Disclosure avoidance for any released microdata or tables. Name the technique: suppression of small cells (n < threshold), rounding, top-coding, noise infusion, or aggregation. For tabular output, state the minimum cell-count rule. Defer the actual pre-release scan to /disclosure-check, and say so in the plan ("released outputs pass /disclosure-check before deposit").