replication-package
Skill150 starsChanged 9 days agoMITView on GitHub
Assemble, anonymize, validate, or audit a research replication package. Use when preparing code and permitted data for reviewer or public release. Not for auditing code quality alone; use $code-suite or $replication-audit as appropriate.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- pedrohcgs/claude-code-my-workflowtheir own version, first seen Nov 8, 2026
- ericluo04/claude-academic-workflowtheir own version, first seen Oct 9, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- pedrohcgs/claude-code-my-workflow★ 1.7ksame name
- ericluo04/claude-academic-workflow★ 25same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository89 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- beamer-deckSkill
- bib-coverageSkill
- bib-filterSkill
- bib-parseSkill
- brief-compliance-checkSkill
- camera-readySkill
- causal-designSkill
- checkpointSkill
- code-archaeologySkill
- compile-knowledgeSkill
- computational-experimentsSkill
- cross-language-checkSkill
- data-analysisSkill
- devils-advocateSkill
- docs-consistencySkill
- docxSkill
- experiment-designSkill
- grill-meSkill
- handoffSkill
- ideasSkill
- init-project-courseSkill
- init-project-lightSkill
- init-project-orchestrationSkill
- init-projectSkill
- insights-deckSkill
- interview-meSkill
- knowledge-lintSkill
- latex-diffSkill
- latex-health-checkSkill
- latex-polishSkill
- latex-postersSkill
- latex-scaffoldSkill
- latexSkill
- latex-templateSkill
- lean-checkSkill
- math-proofSkill
- mcp-builderSkill
- method-auditSkill
- multi-perspectiveSkill
- numerical-checkSkill
- pdfSkill
- pipeline-manifestSkill
- playwright-cliSkill
- postmortemSkill
- pre-commit-auditSkill
- pre-submission-reportSkill
- project-deckSkill
- project-safetySkill
- proof-readabilitySkill
- proofreadSkill
- python-envSkill
- quarto-deckSkill
- reorgSkill
- replication-auditSkill
- retarget-journalSkill
- review-clusterSkill
- review-responseSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 41
Never modify the original project: All work happens on a copy in a sibling folder.
- Distinctive: line 42
Dry-run mandatory: Always show what will be removed/changed and get user confirmation before any deletions.
- Very specific: line 45
Resolve symlinks: Use rsync -aL so symlinked content (e.g., Overleaf paper/ symlinks) becomes real files in the copy.
- Very specific: line 151
Write the manifest to <project>/.context/state/outputs-manifest-<UTC-timestamp>.json, listing every file this skill claims to have written …
- Very specific: line 163
If the verifier exits non-zero, do not commit — surface the missing-files list to the user and stop.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Replication Package — Assemble, Anonymize, and Audit
Build publication-ready replication packages, optionally anonymize for double-blind review, or audit an existing package for reproducibility. The original project is never modified.
Modes
| Mode | What it does | Use case |
| Assemble | Clean copy + AI trace removal + AEA-style README | Sharing, Zenodo deposit, journal supplementary |
| Blind | Everything in Assemble + identity anonymization | Double-blind conference/journal submission |
| Audit | Read-only 11-check reproducibility validation | Pre-deposit quality gate, self-check |
Default mode: Assemble. Infer Blind if the user says "anonymize", "double-blind", or "blind review". Infer Audit if the user says "audit", "check reproducibility", or "validate package".
When to Use
- Submitting supplementary materials or replication files to a journal
- Depositing a package on Zenodo, Dataverse, or ICPSR
- Sharing a project repo publicly (GitHub, institutional repository)
- Preparing for double-blind submission (Blind mode)
- Self-checking reproducibility before deposit (Audit mode)
When NOT to Use
- Quick one-off cleanup of a single file — do it manually
- Removing a single AI artifact — just delete it directly
- Projects with no empirical or computational component
Critical Rules
- Never modify the original project. All work happens on a copy in a sibling folder.
- Dry-run mandatory. Always show what will be removed/changed and get user confirmation before any deletions.
- Binary files are never modified. Warn the user to manually check PDFs (Document Properties), images (EXIF data), and datasets for embedded metadata.
- Self-citations are always interactive. Never auto-remove or auto-anonymize a citation. Flag each potential self-citation and let the user decide per citation. In Blind mode, surface every self-citation against the loaded submission author list and require a per-citation decision (third-person OK / blind the entry). When the cited paper's author list is a subset of the submission's, third-person is structurally insufficient and the bib entry MUST be blinded — see
_shared/double-blind-anonymity-checklist.md§P4–P5. - Resolve symlinks. Use
rsync -aLso symlinked content (e.g., Overleafpaper/symlinks) becomes real files in the copy. - Preserve compilability. The output must still compile/run — only infrastructure and identity are removed, not project functionality.
- Blind mode runs the structured-metadata field check (A2) before reporting clean.
pyproject.toml[project] authors,package.jsonauthor/contributors,Cargo.toml[package] authors,CITATION.cff,LICENSEholder, etc. — see_shared/double-blind-anonymity-checklist.md§"Structured-metadata field check (A2)" for the full target list. This was the CCS 2026 #1328 desk-reject trigger and is now non-skippable.
Assemble Mode (Non-Blind)
Phases 1-7: Scan → Copy → Scrub AI Traces → Generate README → Verify → Fresh Git → Report.
Full workflow: references/assemble-workflow.md
Blind Mode (Assemble + Anonymization)
Runs all Assemble phases, then continues with Phases 8-12: Collect Identity → Anonymize LaTeX → Anonymize Other Files → Anonymous Git → Leak Check Report.
Full workflow: references/blind-workflow.md
Audit Mode (Read-Only)
11-check reproducibility validation: Compilation, Script order, Output presence, Dependencies, Data provenance, README, File sizes, End-to-end clarity, AI traces, Identity leaks, Numeric reproduction.
Full workflow: references/audit-workflow.md
Check 11 (Numeric reproduction) is N/A unless an expected_values.json (the manuscript's reported numbers) sits at the package root. When present, the audit parses the package's committed output files and scores them against that ground truth within tolerance — catching paper-vs-output drift. It is read-only and never re-runs scripts. Convention + scoring rubric: references/expected-values-schema.md.
HPC-run results
If the project used [HPC cluster] (hpc/ directory with *.sbatch), the results in out/<jobid>/ should include git-sha.txt + git-status.txt (written by the sbatch templates before srun). Audit must verify these exist and the SHA matches a commit in the repo — this is the compute-reproducibility equivalent of Script order + Dependencies for HPC runs. The Assemble README should document the hpc/ entry point and the HF/conda env-setup script alongside code/ + data/. See Task Management docs/guides/hpc.md.
What This Skill Does NOT Do
- Does not modify the original project — all changes are in the sibling folder (Assemble/Blind) or purely read-only (Audit).
- Does not modify binary files — PDFs, images, datasets are copied as-is. User must check these manually for embedded metadata.
- Does not auto-handle self-citations — every potential self-citation requires user decision.
- Does not anonymize the paper title — titles are generally not considered identifying (but some venues disagree; user should check).
- Does not strip PDF metadata — if a compiled PDF exists, its Document Properties may contain author info. User should recompile from the anonymized source or use
exiftoolto strip metadata. - Does not run scripts — it verifies their presence and order but does not execute them (too risky without a controlled environment). Check 11 (Numeric reproduction) likewise compares the package's already-committed output files against the manuscript; it never re-runs the pipeline, so it catches paper-vs-output drift, not full fresh-run reproduction.
Examples
Assemble mode (default)
"Build a replication package for my research paper"
Runs Assemble mode on the current project, creates ../mcdm-paper-replication/.
Blind mode
"Anonymize my paper for AAAI double-blind submission"
Runs Blind mode, creates ../mcdm-paper-replication-blind/.
Audit mode
"Audit the reproducibility of my replication package"
Runs Audit mode (read-only) on the specified package directory.
Explicit path and mode
"replication-package
<project-path>--mode blind"
Runs Blind mode on the specified project path.
Cross-References
data-sensitivityrule — raw data is read-only; replication packages must document data provenance without modifyingdata/raw/overleaf-separationrule —paper/structure is preserved; symlinks resolved by rsyncshared/multi-language-conventions.md— dependency detection patterns for Python, R, Julia, MATLABshared/publication-output.md— output file verification and freshness checkslatex— compilation check in Audit modereferences/aea-readme-template.md— AEA-style README template for Assemble modereferences/figure-table-crosswalk.md— per-figure/table crosswalk (with LaTeX Label) + paper-consistency check, appended to the README (Phase 4)references/logging-skeletons.md— per-script logging + master-script skeletons (R/Python/Julia/Stata) offered in Phase 5references/release-readiness-checklist.md— 14-point PASS/FAIL pre-release gate emitted at Phase 7 (RELEASE-READINESS.md)references/rules.dropboxignore— Dropbox-sync ignore file for Dropbox-synced packages (Phase 6)references/anonymization-patterns.md— replacement tables for Blind modereferences/audit-rubric.md— 11-check scoring rubric for Audit modereferences/expected-values-schema.md—expected_values.jsonconvention + numeric-reproduction scoring rubric (Check 11)references/deposit-checklist.md— platform-specific deposit completeness checklistreferences/report-template.md— report format for Blind mode_shared/double-blind-anonymity-checklist.md— authoritative paper+artifact anonymity matrix (P1–P8, A1–A9). Blind mode must run all artifact-side checks (A1–A9) before reporting clean.
Note: This skill replaces the former
/export-project-cleanand/export-project-anonskills. All their functionality is preserved in Assemble and Blind modes respectively.
Output Verification (Guard)
This skill writes files. Before any auto-commit, emit an outputs manifest and run the shared verifier. See skills/_shared/verify-outputs.md for the full protocol.
Required tail steps (before git commit):
- Write the manifest to
<project>/.context/state/outputs-manifest-<UTC-timestamp>.json, listing every file this skill claims to have written in this invocation (paths relative to the project root). Run:
uv run python "<skills-root>/_shared/verify_outputs.py" \ --manifest "$MANIFEST" \ --project-root "$PROJECT_ROOT"- If the verifier exits non-zero, do not commit — surface the missing-files list to the user and stop. The verifier has already logged an
errorentry to~/.local/state/ai-workflows/skill-outcomes.jsonl, which feeds the shared skill-health dashboard.
Why: closes the "hallucinated outputs" failure class (commit b2cff75, 2026-04-18).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

