Use when preparing the data availability statement and the data/code archive for a Global Change Biology (GCB) manuscript. GCB requires data and code to be archived in a public repository with a persistent DOI as a condition of publication, and \"available on request\" is not accepted. Prepares the deposit; it does not waive requirements.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill gcb-reporting-and-data-policy --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Gcb Reporting And Data Policy?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-gcb-reporting-and-data-policy)More formats (shields.io, HTML) on the badges page.
---
name: gcb-reporting-and-data-policy
description: "Use when preparing the data availability statement and the data/code archive for a Global Change Biology (GCB) manuscript. GCB requires data and code to be archived in a public repository with a persistent DOI as a condition of publication, and \"available on request\" is not accepted. Prepares the deposit; it does not waive requirements."
category: backend-and-data
source_repo: brycewang-stanford/Awesome-Journal-Skills
source_path: "Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md"
source_url: https://github.com/brycewang-stanford/Awesome-Journal-Skills/blob/HEAD/Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md
---
# Reporting & Data Policy (gcb-reporting-and-data-policy)
GCB treats open data and code as a **condition of publication**, not a courtesy. Primary and secondary
data supporting the results must be **archived in a publicly accessible repository with a persistent
identifier (DOI)**, code/software likewise (e.g., Zenodo), and the manuscript must carry a **data
availability statement**. Crucially, **"available on request" is not accepted**. Build the deposit as
you go. Confirm current wording on the policy page before submission.
## When to trigger
- Writing the **data availability statement**
- Choosing repositories and minting DOIs for data and code
- Handling data that cannot be fully shared (sensitive species locations, third-party/licensed data)
- Final reporting checks before submission
## What GCB requires (verify current wording)
1. **Archive data with a DOI.** Deposit primary and secondary data in a public, DOI-minting repository
(e.g., **Dryad**, **Zenodo**, **PANGAEA**) with metadata sufficient for a third party to interpret
the data correctly — before acceptance/publication.
2. **Archive code with a DOI.** Code, software, and documentation supporting the results go to an
appropriate public repository (e.g., **Zenodo** via a GitHub release) with a persistent identifier.
3. **Data availability statement.** State exactly where the data and code live and how to access them;
**"available on request" is not sufficient**.
4. **Reviewer access.** Make data accessible to peer reviewers on request during evaluation.
5. **Reporting completeness.** Report sample sizes, replication, units, methods, and software versions
well enough to reproduce every result.
## When data cannot be fully shared
- **Sensitive data** (e.g., precise locations of threatened species, human-subjects or provider-licensed
data): explain the restriction, give a **clear access pathway** (provider, application process), and
share what can be shared (de-sensitized/aggregated layers) plus full code.
- Document why the restriction applies; do not use sensitivity as a blanket reason to skip deposit.
## Build-as-you-go checklist
- [ ] Data archived in a DOI-minting public repository with interpretable metadata
- [ ] Code/software archived (Zenodo/GitHub release) with a DOI
- [ ] Data availability statement names repository + access (not "on request")
- [ ] Sample sizes, replication, units, software versions reported
- [ ] Sensitive data: restriction explained + access pathway + shareable subset
- [ ] Manuscript exhibit numbers match the archived outputs
## Repository fit by data type
Different global-change data types land best in different DOI-minting archives. Treat this as a routing
guide, then confirm the current accepted list against the journal's author guidelines.
| Data type | Typical archive | Note |
|-----------|-----------------|------|
| Ecological tabular / experimental | Dryad | Curated, ecology-oriented |
| Code + figure pipeline | Zenodo via a GitHub release | Versioned, DOI per release |
| Oceanographic / Earth-system | PANGAEA | Geo/environmental specialist |
| Sequences | INSDC (GenBank/ENA) | Domain-mandated, then cite accession |
| Sensitive species locations | Restricted deposit + access pathway | Share de-sensitized layer + full code |
## Worked micro-example (illustrative)
A remote-sensing carbon-flux paper archives three things, not one: the gap-filled flux table to a
DOI-minting repository; the processing and modelling code to Zenodo via a tagged GitHub release; and the
raw tower coordinates with a stated restriction because one site is on a protected reserve. The data
availability statement names each DOI and the access route for the restricted coordinates. A weak version
deposits only the figures' CSV and writes "code available on request" — which GCB does not accept. The
DOIs here are illustrative placeholders; mint real ones before submission.
## Compliance pushback patterns and the fix
- "Statement says available on request" → replace with named repository, DOI, and access route; GCB does
not accept request-only.
- "Code not archived, only data" → deposit the analysis/modelling code so every figure reproduces.
- "Metadata insufficient" → add units, sampling design, and variable definitions a third party can read.
- "Sensitive locations withheld with no pathway" → explain the restriction, give the application route,
and share an aggregated layer plus full code.
## Anti-patterns
- "Data available on request" (explicitly rejected by GCB)
- A personal website or transient cloud link instead of a DOI-minting repository
- Archiving data but not the code that produced the figures
- Metadata too thin for a third party to interpret the data
- Treating deposit as a post-acceptance afterthought
## Output format
```
【Data archived】DOI-minting repo + metadata? [Y/N]
【Code archived】Zenodo/release with DOI? [Y/N]
【Availability statement】names repo + access (not "on request")? [Y/N]
【Sensitive data】restriction explained + access path + shareable subset?
【Reproducible reporting】n, units, versions complete? [Y/N]
【Next】gcb-writing-style
```
## Supplementary resources
- [`../../resources/external_tools.md`](../../resources/external_tools.md) — repositories (Dryad/Zenodo/PANGAEA) and reproducibility tooling
- [`../../resources/official-source-map.md`](../../resources/official-source-map.md) — GCB data- and code-archiving policy
---
**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!