agentsclimarketplace

Io transparency and data policy

Skill brycewang-stanford/Awesome-Journal-Skills/International-Organization-Skills/skills/io-transparency-and-data-policy

Use when preparing the replication/transparency materials for an International Organization (IO) manuscript. IO's signature requirement is verification BEFORE final acceptance — the editorial staff request data and code at conditional acceptance, IO staff re-run quantitative results and check proofs of formal models, and editors withhold final acceptance until all reported results are confirmed; materials then deposit to the IO Dataverse with a DOI and a Data Availability Statement. Prepares the package; it does not waive requirements.From its SKILL.md

Install
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill io-transparency-and-data-policy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Transparency & Data Policy (io-transparency-and-data-policy)

IO does not just ask for data — its editorial staff re-run your quantitative results and verify the proofs of your formal models, and editors will not issue final acceptance until all reported analyses are confirmed. This pre-publication verification is IO's signature. Build the package as you analyze so conditional acceptance does not stall.

When to trigger

  • Building the reproducibility/replication package (start during analysis, not at acceptance)
  • A manuscript reached conditional acceptance and the editorial staff requested data and code
  • You have a formal model whose proofs IO staff will verify
  • Data cannot be fully shared (privacy, ethics, legal/provider restrictions) and you need the path
  • Writing the Data Availability Statement

What IO requires (verify current wording on the policy page — 待核实 on verbatim text)

  1. No data at initial submission. Authors do not provide data or command files when first submitting (consistent with double-blind review).
  2. Data requested at conditional acceptance. The editorial staff request the data and command files at the time of conditional acceptance.
  3. Verification before final acceptance. For papers using quantitative data, IO staff re-run the code to confirm the reported results; for formal papers, IO staff verify the proofs. Editors do not issue final acceptance until all results of all reported analyses are confirmed. Treat this as a real check, not a formality.
  4. Deposit to the IO Dataverse. On final acceptance, upload quantitative datasets and supporting files to the IO Dataverse on Harvard Dataverse; the entry mints a DOI to be cited in the published article. Not a personal website or generic cloud link.
  5. Data Availability Statement. A DAS is required for quantitative articles (encouraged for qualitative), appearing before the reference list.
  6. Qualitative materials. Authors are strongly encouraged to deposit qualitative data at the Qualitative Data Repository (QDR) at Syracuse, with access controls where needed.

When data cannot be shared (exemption path)

  • Explain why the relevant data are not available (ethical/privacy concerns or legal restrictions by the provider).
  • Provide README instructions on exactly how others can obtain the data (access process, application, provider contact).
  • Where possible, provide synthetic or simulated data so the code runs end-to-end. (Confirm the current exemption procedure on the live policy page — 待核实.)

Build-as-you-go checklist

  • One master script regenerates every table and figure from raw/constructed data
  • README documents data provenance, construction steps, software, and how to reproduce each exhibit
  • Seeds set and reported for every stochastic step
  • Software/package versions pinned (renv.lock / requirements.txt / recorded installs)
  • Exhibit numbers in the manuscript match the package output exactly (IO staff re-run them)
  • Formal models: a complete, checkable proof appendix for IO staff to verify
  • Data Availability Statement drafted (before the reference list)
  • Restricted data: exemption note + access instructions + synthetic data where feasible
  • Qualitative data: QDR deposit considered; sources documented for the claims

Anti-patterns

  • Treating the deposit as a post-publication afterthought (it gates final acceptance)
  • Depositing code that does not actually reproduce the printed tables/figures (IO re-runs it)
  • A formal model with hand-waved or incomplete proofs (IO verifies proofs)
  • A personal URL instead of the IO Dataverse; no DOI cited in the article
  • Claiming data are restricted without giving an access path or synthetic substitute
  • Forgetting the Data Availability Statement

Output format

【Stage】initial (no data) / conditional acceptance (data requested) / pre-final (verification)
【Quantitative reproduces?】master script re-runs all tables/figures locally? [Y/N]
【Formal proofs】complete, checkable proof appendix? [Y/N/NA]
【Repository】IO Dataverse (Harvard) staged + DOI plan? [Y/N]
【Data Availability Statement】drafted before references? [Y/N]
【Restricted data?】exemption note + access path + synthetic data?
【Qualitative】QDR deposit + sources documented? [Y/N/NA]
【Next】io-review-process

Supplementary resources

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.