Mmcp.market

data-management-plan skill

by pedrohcgs·pedrohcgs/claude-code-my-workflow·1.6k stars·MIT

Draft a funder-compliant Data Management Plan (NSF DMP, NIH DMS Policy 2023, ERC, Horizon Europe) by composing the confidential-data and environment-capture primitives. Sections cover data description, formats/metadata, storage/backup, access/sharing, preservation/archiving, and roles. Use when user says "data management plan", "DMP", "DMSP", "NIH data sharing plan", "write the data plan for my grant", or when a grant proposal needs a data-management section. NOT a submission tool — produces a draft the user pastes into the funder portal (DMPTool, NIH ASSIST, Horizon Europe portal).

A100/100content scan

Is the data-management-plan skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the data-management-plan skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow
mkdir -p ~/.claude/skills
cp -r /tmp/claude-code-my-workflow/.claude/skills/data-management-plan ~/.claude/skills/data-management-plan
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

/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 — 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:
  1. 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: ] 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").

Phase 3 — Fold in the computational-environment + replication-package plan

The DMP should commit to reproducibility, not just data deposit:

  • Environment capture. State that the computational environment will be captured (R sessionInfo() / renv.lock, Stata version + .do ado dependencies, Python requirements.txt / container). Point to /capture-environment as the mechanism. AEA Data Editor / DCAS standards expect this.
  • Replication package. Commit to depositing a replication package (code + non-restricted data + a master run script + README) in a trusted repository. Point to /replication-package as the builder.
  • Repository choice — match the data class:
  • Economics / social science → openICPSR (AEA's home; DCAS-compliant) or Harvard Dataverse.
  • Restricted data → openICPSR restricted-access tier or the provider's enclave (FSRDC); deposit code + metadata, not the microdata.
  • Domain repos → field-specific (e.g., ICPSR proper, GenBank, Zenodo for code) where the funder or community expects them.
  • State the persistent identifier (DOI) and the timeline (e.g., "at publication" or "within 12 months of project end" — NIH expects no later than publication or award end).

Phase 4 — Post-flight (skip with --no-verify)

If the draft cites a funder policy or standard by name/number (e.g., "per NIH NOT-OD-21-013", "DCAS v1"), invoke /verify-claims via the Agent tool to confirm the policy citation resolves. Forked claim-verifier never sees the draft. Surface any FAIL/PARTIAL.

Phase 5 — Output

Write the draft to qualityreports/dmp/YYYY-MM-DD.md and a funder checklist alongside it.

✓ DMP draft saved: quality_reports/dmp/<file>.md
  Funder: <nsf|nih|erc|horizon>   Data class: <public|restricted|human-subjects>
  Sections: <count> total — <complete> complete, <clarify> with [CLARIFY:] placeholders
  Disclosure/IRB folded in: <yes (Phase 2) | n/a — public data>
  Repository: <openICPSR | Dataverse | domain repo>   PID: <DOI planned | [CLARIFY:]>
  Policy citations verified: <PASS>/<PARTIAL>/<FAIL>  (or "none to verify")
  Next: resolve [CLARIFY:] items, then paste into <DMPTool | NIH ASSIST | Horizon portal>

The funder checklist is a table: each required section → present? → complete / [CLARIFY:], so the user sees at a glance whether the plan will pass the funder's compliance check.

Exit behavior

  • All required sections present, zero [CLARIFY:] → "DMP READY", checklist all green.
  • Any required section unresolved → "INCOMPLETE — N MUST items unresolved", listed in the checklist. The draft is still written (so the user can fill it in), but not marked ready.
  • This skill does not block anything — it produces a document. The gate is the funder's, not ours.

Cross-references

  • .claude/rules/confidential-data.md — restricted-data / IRB / disclosure-avoidance rules folded in at Phase 2.
  • .claude/skills/disclosure-check/SKILL.md — pre-release disclosure scan the plan commits released outputs to.
  • .claude/skills/capture-environment/SKILL.md — the environment-capture mechanism Phase 3 references.
  • .claude/skills/replication-package/SKILL.md — the replication-package builder Phase 3 commits to.
  • .claude/skills/grant-proposal/SKILL.md — follows this skill (via an Agent that reads this SKILL.md) for the proposal's data-management section.
  • .claude/skills/preregister/SKILL.md — sibling document-generator; shares the MUST/[CLARIFY:] + post-flight conventions.
  • .claude/rules/replication-protocol.md — the reproducibility contract the deposited package must satisfy.

What this skill does NOT do

  • Submit the plan. It writes a Markdown draft; the user pastes it into DMPTool / NIH ASSIST / the Horizon portal.
  • Run the disclosure scan or build the package. It commits the project to /disclosure-check, /capture-environment, and /replication-package, and references them — it does not execute them.
  • Write the IRB protocol. It references the protocol number and consent terms; the protocol is authored separately.
  • Choose a repository for you when the funder mandates one. If NIH names a domain repository for your data type, that mandate wins over the defaults in Phase 3 — the skill flags it as [CLARIFY:] rather than guessing.

More skills from pedrohcgs/claude-code-my-workflow

  • Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
  • Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
  • Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
  • Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
  • AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
  • AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
  • Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
  • AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
  • Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
  • Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
  • Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
  • Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).

All agent skills → · MCP servers