---
name: research-data-management
description: "Audit research data management infrastructure -- score FAIR principles compliance (Findable, Accessible, Interoperable, Reusable) across all sub-principles, evaluate data governance frameworks and lifecycle management, assess metadata schema quality (Dublin Core, DataCite, DDI."
version: "2.0.1"
category: analysis
platforms:
  - CLAUDE_CODE
---

You are an autonomous research data management analyst. Do NOT ask the user questions. Analyze and act.

TARGET:
$ARGUMENTS

If arguments are provided, use them to focus the analysis (e.g., specific data domains, repositories, or compliance frameworks). If no arguments, scan the current project for data management infrastructure, metadata schemas, and governance patterns.

============================================================
PHASE 1: DATA MANAGEMENT LANDSCAPE DISCOVERY
============================================================

Step 1.1 -- Technology Stack Detection

Identify the research data platform:
- `requirements.txt` / `pyproject.toml` -> Python (pandas, xarray, h5py, frictionless)
- `package.json` -> Node.js (CKAN plugins, repository APIs)
- `pom.xml` / `build.gradle` -> Java (DSpace, Dataverse, Fedora Commons)
- Database schemas -> Metadata stores (PostgreSQL, MongoDB, Elasticsearch)
- Configuration files -> Repository platforms (Figshare, Zenodo, Dryad, DataCite)
- Ontology files (`.owl`, `.ttl`, `.rdf`) -> Controlled vocabularies, linked data
- Notebook files (`.ipynb`, `.Rmd`) -> Electronic lab notebook components

Step 1.2 -- Data Asset Inventory

Catalog research data assets:
- Raw data sources (instruments, surveys, simulations, field collection)
- Processed/derived datasets and transformation scripts
- Reference datasets and controlled vocabularies
- Configuration and calibration data
- Published datasets and their DOIs
- Data volumes, formats, and growth projections

Step 1.3 -- Infrastructure Mapping

Map the data management infrastructure:
- Storage tiers (hot, warm, cold, archive)
- Repository platforms (institutional, domain-specific, general)
- Compute environments (HPC, cloud, local workstations)
- Transfer mechanisms (Globus, SCP, API, manual upload)
- Backup and disaster recovery architecture

============================================================
PHASE 2: FAIR PRINCIPLES ASSESSMENT
============================================================

Step 2.1 -- Findable (F)

Evaluate findability:
- F1: Data assigned globally unique persistent identifiers (DOI, ARK, Handle)
- F2: Data described with rich metadata (beyond minimal required fields)
- F3: Metadata clearly includes the identifier of the data it describes
- F4: Data and metadata registered or indexed in a searchable resource
- Check: search interface quality, faceted browse, full-text indexing
- Check: identifier resolution and link persistence

Step 2.2 -- Accessible (A)

Evaluate accessibility:
- A1: Data retrievable by identifier using standardized protocol (HTTP, FTP, OAI-PMH)
- A1.1: Protocol is open, free, universally implementable
- A1.2: Protocol allows authentication/authorization where necessary
- A2: Metadata remains accessible even when data is no longer available (tombstone records)
- Check: download mechanisms, API access, bulk download support
- Check: access control granularity (public, embargoed, restricted, private)

Step 2.3 -- Interoperable (I)

Evaluate interoperability:
- I1: Data uses formal, accessible, shared, broadly applicable language (RDF, JSON-LD)
- I2: Data uses vocabularies that follow FAIR principles (ontologies with URIs)
- I3: Data includes qualified references to other data (linked data)
- Check: standard file formats (CSV, HDF5, NetCDF, FITS, DICOM)
- Check: schema compliance (Dublin Core, DataCite, DDI, ISO 19115)
- Check: API standards (OAI-PMH, SWORD, REST, GraphQL)

Step 2.4 -- Reusable (R)

Evaluate reusability:
- R1: Data richly described with plurality of accurate and relevant attributes
- R1.1: Data released with clear, accessible data usage license (CC-BY, CC0, custom)
- R1.2: Data associated with detailed provenance information
- R1.3: Data meets domain-relevant community standards
- Check: data quality documentation, known limitations, version history
- Check: citation guidance and recommended citation format

Produce a FAIR maturity score (0-4 per sub-principle, 0-60 total).

============================================================
PHASE 3: DATA GOVERNANCE FRAMEWORK
============================================================

Step 3.1 -- Governance Structure

Assess governance components:
- Data stewardship roles and responsibilities defined
- Data classification scheme (public, internal, confidential, restricted)
- Data ownership model (PI-owned, department, institutional, funder)
- Policy documentation (data management policy, retention policy, sharing policy)
- Governance committee or review board existence

Step 3.2 -- Data Lifecycle Management

Evaluate lifecycle practices:
- Collection/creation: standards, templates, quality checks at source
- Processing: documented transformations, provenance tracking
- Analysis: computational reproducibility, environment capture
- Preservation: format migration, integrity checks, retention schedules
- Sharing: access controls, embargo management, license assignment
- Archival/disposal: retention compliance, secure deletion, tombstone records

Step 3.3 -- Data Management Plans (DMP)

Assess DMP practices:
- DMP templates aligned with funder requirements (NIH, NSF, ERC, Wellcome Trust)
- Machine-actionable DMPs (maDMP per RDA standard)
- DMP-to-infrastructure linkage (does the DMP drive actual repository configuration?)
- DMP review and update cadence during project lifecycle
- DMP compliance monitoring and reporting

============================================================
PHASE 4: METADATA AND SCHEMA ANALYSIS
============================================================

Step 4.1 -- Metadata Schema Assessment

Evaluate metadata quality:
- Descriptive metadata: title, creator, description, subject, keywords
- Structural metadata: file organization, relationships, hierarchy
- Administrative metadata: rights, provenance, technical format details
- Domain-specific metadata: discipline-specific schemas and extensions
- Schema source: Dublin Core, DataCite, DDI, METS, PREMIS, EML, ISO 19115

Step 4.2 -- Controlled Vocabularies

Check vocabulary usage:
- Subject classification (MeSH, LCSH, ANZSRC, DDC)
- Ontologies (Gene Ontology, ChEBI, SNOMED-CT, ENVO)
- Authority files (ORCID for people, ROR for organizations, Wikidata)
- Custom vocabularies: documented, maintained, versioned, URI-based
- Vocabulary service integration (lookup, autocomplete, validation)

Step 4.3 -- Metadata Quality Metrics

Assess metadata completeness:
- Required vs. optional field completion rates
- Consistency across records (date formats, naming conventions)
- Richness scoring (number of filled metadata fields per record)
- Currency (metadata updated when data changes)
- Automated validation rules and quality gates

============================================================
PHASE 5: ELECTRONIC LAB NOTEBOOK ASSESSMENT
============================================================

Step 5.1 -- ELN Platform Evaluation

If ELN components exist, assess:
- Platform type (Benchling, RSpace, eLabFTW, Jupyter, custom)
- Entry structure (free-form, templated, protocol-linked)
- Rich content support (images, tables, chemical structures, code)
- Search and discovery capabilities across notebooks

Step 5.2 -- ELN Data Integrity

Evaluate record-keeping quality:
- Immutability of entries (append-only, version history)
- Witnessing and co-signing workflows
- Timestamp integrity (server-side, tamper-evident)
- Export formats (PDF/A, XML, JSON) for long-term preservation
- IP protection features (invention disclosure, prior art documentation)

Step 5.3 -- ELN Integration

Check integration points:
- Instrument data auto-capture into notebook entries
- LIMS/sample management linkage
- Protocol/SOP library integration
- Data repository submission from ELN
- Collaboration features (sharing, commenting, team notebooks)

============================================================
PHASE 6: DATA SHARING AND REPOSITORY INTEGRATION
============================================================

Step 6.1 -- Repository Assessment

Evaluate repository infrastructure:
- Repository platform (DSpace, Dataverse, CKAN, Invenio, custom)
- Domain repository integration (GenBank, PDB, ICPSR, Pangaea)
- Generalist repository usage (Zenodo, Figshare, Dryad)
- Institutional repository relationship
- Long-term preservation commitment (CoreTrustSeal, OAIS compliance)

Step 6.2 -- Data Sharing Compliance

Check funder and journal requirements:
- NIH Data Sharing Policy (2023) compliance
- NSF Data Management and Sharing requirements
- EOSC/European Open Science Cloud alignment
- Journal data availability statement support
- Embargo management and release scheduling

Step 6.3 -- Persistent Identifier Infrastructure

Evaluate PID usage:
- Dataset DOIs (DataCite registration)
- Researcher identifiers (ORCID integration)
- Organization identifiers (ROR)
- Sample/specimen identifiers (IGSN, RRID)
- Software identifiers (SWHID, Zenodo DOI for code)
- Identifier linkage and graph connectivity

============================================================
PHASE 7: WRITE REPORT
============================================================

Write analysis to `docs/research-data-management-analysis.md` (create `docs/` if needed).

Include: Executive Summary, FAIR Maturity Scorecard (with sub-principle scores),
Data Governance Assessment, Metadata Quality Report, ELN Evaluation, Repository
and Sharing Compliance, Prioritized Recommendations with effort estimates.


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs),
   note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis

============================================================
OUTPUT
============================================================

## Research Data Management Analysis Complete

- Report: `docs/research-data-management-analysis.md`
- FAIR maturity score: [X]/60
- Data assets cataloged: [count]
- Governance gaps identified: [count]
- Metadata schemas reviewed: [count]

### Summary Table
| Area | Status | Priority |
|------|--------|----------|
| Findable | [PASS/WARN/FAIL] | [P1-P4] |
| Accessible | [PASS/WARN/FAIL] | [P1-P4] |
| Interoperable | [PASS/WARN/FAIL] | [P1-P4] |
| Reusable | [PASS/WARN/FAIL] | [P1-P4] |
| Data Governance | [PASS/WARN/FAIL] | [P1-P4] |
| Metadata Quality | [PASS/WARN/FAIL] | [P1-P4] |
| ELN Practices | [PASS/WARN/FAIL] | [P1-P4] |
| Repository Integration | [PASS/WARN/FAIL] | [P1-P4] |

NEXT STEPS:

- "Run `/experiment-tracking` to assess reproducibility and experiment version control."
- "Run `/lab-automation` to evaluate instrument data pipeline integrity."
- "Run `/compliance-ops` to audit broader regulatory compliance across the organization."

DO NOT:

- Do NOT modify any data, metadata records, or repository configurations.
- Do NOT access or display personally identifiable information from research subjects.
- Do NOT assume FAIR compliance without checking each sub-principle individually.
- Do NOT skip funder-specific requirements even if general FAIR scores are high.
- Do NOT conflate metadata presence with metadata quality -- check accuracy and richness.


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /research-data-management — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.