Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› io-transparency-and-data-policy
io-transparency-and-data-policy
GitHub用于准备国际组织（IO）期刊的透明性与数据政策材料。核心在于协助作者构建可复现包，应对条件接受阶段的数据与代码验证要求，处理正式模型证明核查，并指导数据归档至IO Dataverse及撰写数据可用性声明。
Trigger Scenarios
准备IO期刊稿件的可复现/复制包
稿件获有条件接受且编辑部要求提供数据和代码
包含需由编辑部验证证明的正式模型
因隐私或法律原因无法完全共享数据
撰写数据可用性声明
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill io-transparency-and-data-policy -g -y
SKILL.md
Frontmatter
{
"name": "io-transparency-and-data-policy",
"description": "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."
}
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)
- No data at initial submission. Authors do not provide data or command files when first submitting (consistent with double-blind review).
- Data requested at conditional acceptance. The editorial staff request the data and command files at the time of conditional acceptance.
- 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.
- 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.
- Data Availability Statement. A DAS is required for quantitative articles (encouraged for qualitative), appearing before the reference list.
- 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
../../resources/external_tools.md— reproducibility tooling, formal-proof workflow, and QDR for qualitative IR../../resources/official-source-map.md— IO Research Transparency policy + IO Dataverse
Version History
- 1839142 Current 2026-07-05 13:23
