PluginBench
Skill
Review
Audit score 70

ai-research-reproduction

lllllllama/rigorpilot-skills

README-first deep learning repository reproduction with auditable evidence and conservative patch rules.

What is ai-research-reproduction?

Guides reproducible execution of deep learning research code by reading the repository first, selecting the smallest documented inference or evaluation target, and recording all assumptions, deviations, and decisions in a standardized output bundle. Use this when you need end-to-end, trustworthy reproduction that preserves documented intent rather than silent fixes or score chasing.

  • Reads repository README and selects the smallest documented inference or evaluation target
  • Orchestrates setup, trusted execution, and optional training with explicit user confirmation gates
  • Records evidence, assumptions, deviations, and human decision points in standardized `repro_outputs/` bundle
  • Enforces conservative patch rules: prefers command-line fixes and environment variables over code changes
  • Generates annotated README, commands log, scientific changelog, and comparability report
  • Detects command-set changes and fails closed rather than silently adapting

How to install ai-research-reproduction

npx skills add https://github.com/lllllllama/rigorpilot-skills --skill ai-research-reproduction
Prerequisites
  • Python 3.11 or higher
  • Git for repository management
  • Target repository may require additional reviewed dependencies, network access, or GPU/accelerators
Claude Code
Cursor
Windsurf
Cline

How to use ai-research-reproduction

  1. 1.Run `scripts/orchestrate_repro.py --repo <repo> --plan-only --agent-output` to review candidate commands and selection fingerprint
  2. 2.Inspect the `command_candidates` and selected `cmd-XX` with its side-effect contract
  3. 3.Run the reviewed candidate with `--run-selected --command-id <cmd-XX> --plan-fingerprint <fingerprint> --agent-output` plus any timeout bounds
  4. 4.Run `--verify-output --agent-output` and inspect evidence files only if verification fails
  5. 5.Review the `repro_outputs/` bundle (SUMMARY.md, COMMANDS.md, SCIENTIFIC_CHANGELOG.md, COMPARABILITY_REPORT.md) and deliver the bounded result

Use cases

Good for
  • Reproducing a published deep learning paper's inference or evaluation on the original repository
  • Verifying that a model checkpoint produces documented baseline metrics
  • Auditing whether repository code matches paper claims with explicit deviation tracking
  • Establishing a trustworthy baseline before making experimental modifications
  • Creating reproducible evidence bundles for research validation or peer review
Who it's for
  • ML researchers verifying published results
  • Research engineers auditing code-to-paper fidelity
  • Teams needing auditable reproduction records for compliance or publication
  • Anyone reproducing deep learning work who needs to distinguish verified facts from inference

ai-research-reproduction FAQ

When should I use this skill vs. generic setup or paper summaries?

Use this skill only for repository-grounded, multi-phase trusted reproduction with a concrete smallest target (inference, evaluation, or training startup). Do not use it for paper summaries, generic environment setup, isolated repo scanning, or open-ended research design.

What if the README and paper conflict on how to run the experiment?

Treat README guidance as primary reproduction intent. Record the conflict explicitly and use `paper-context-resolver` only for the narrow reproduction-critical gap, not to silently replace documented meaning.

Can I modify the repository code during reproduction?

Prefer no edits. If edits are necessary, keep them conservative (command-line args, environment variables, dependency fixes first), create a `repro/YYYY-MM-DD-task` branch, and record all changes and their scientific impact in PATCHES.md.

What happens if the command set changes between planning and execution?

The skill fails closed and requires re-planning. Do not wrap the orchestrator in an equal or shorter external timeout; it needs time to terminate children and write terminal evidence.

How do I know if reproduction succeeded?

Award `result-match` only against explicit expected metrics and tolerance stated in the README or paper. Process success alone is not reproduction success; inspect COMPARABILITY_REPORT.md for detailed fidelity assessment.

Full instructions (SKILL.md)

Source of truth, from lllllllama/rigorpilot-skills.


name: ai-research-reproduction description: Rigor Reproduce compatible skill slug for README-first deep learning repository reproduction. Use when the user wants an end-to-end, minimal-trustworthy flow that reads the repository first, selects the smallest documented inference or evaluation target, coordinates intake, setup, trusted execution, optional trusted training, optional repository analysis, and optional paper-gap resolution, enforces conservative patch rules, records evidence assumptions deviations and human decision points, and writes the standardized repro_outputs/ bundle. Do not use for paper summary, generic environment setup, isolated repo scanning, standalone command execution, silent protocol changes, score chasing, or broad research assistance outside repository-grounded reproduction. compatibility: Requires Python 3.11+ and Git for bundled orchestration; target repositories may require additional reviewed dependencies, network access, or accelerators.

ai-research-reproduction

Purpose

Guide README-first deep learning reproduction toward the smallest trustworthy run with auditable evidence. Preserve documented meaning; record assumptions, deviations and blockers instead of changing semantics to manufacture success. Load specialized references only for a concrete uncertainty.

Fast Path

For a routine bounded run, keep the control path short:

  1. Read the target README and only the target test/config/source needed to understand the documented command.
  2. Run scripts/orchestrate_repro.py --repo <repo> --plan-only --agent-output with any explicit user timeout bound (--timeout or --train-timeout) already supplied; review command_candidates, the selected cmd-XX, side-effect contract, selection fingerprint, and returned reviewed_run_args. With no --output-dir, later evidence goes to <repo>/repro_outputs regardless of caller cwd.
  3. Run the selected candidate, or another reviewed candidate, with --run-selected --command-id <cmd-XX> --plan-fingerprint <fingerprint> --agent-output plus requested timeout/metric/source-adjacent options. Preserve an explicit user command-timeout bound instead of silently making it stricter on a routine trusted run. --timeout limits the target command; do not wrap the whole orchestrator in an equal or shorter external timeout, because it still needs time to terminate children and write terminal evidence. A changed command set fails closed; setup/download commands are never target candidates.
  4. Run --verify-output --agent-output; inspect detailed evidence files only when verification fails or the result is partial/blocked.
  5. Deliver the bounded result and stop.

For a host with short tool-call deadlines, rerun planning with --include-agent-handoff and follow references/agent-job.md; otherwise keep the direct path above. Job completion is not task acceptance, and uncertain state is never a reason for automatic replay.

Do not inspect orchestrate_repro.py, annotate_readme.py, _bundled/, writers, or runtime internals on a normal success path. Inspect implementation only for a concrete blocker, unexpected side effect, bundle-integrity failure, or unresolved safety question. Use scripts/doctor.py for first-use environment/install diagnostics. Executed commands keep full lifecycle/log evidence under repro_outputs/_runtime/<run_id>/.

Fit

Use this skill for repository-grounded, multi-phase trusted reproduction where the goal is a small reproducible target. Do not use it for paper summaries, generic setup, isolated scanning, standalone commands, open-ended research design, or explicitly authorized candidate exploration.

Trusted Target Selection

Choose the smallest target that can honestly demonstrate repository-grounded reproduction:

  1. documented inference
  2. documented evaluation
  3. documented training startup or partial verification
  4. full training only after explicit user confirmation

Treat README guidance as the primary reproduction intent. Use repository files to clarify the README, not to silently replace it. When the README and paper conflict, record the conflict and use paper-context-resolver only for the narrow reproduction-critical gap.

Workflow

  1. Treat README guidance as primary; extract and select the minimum trustworthy target.
  2. Use setup/assets only for target-specific prerequisites and analyze-project only when structural clarification is needed.
  3. Use minimal-run-and-audit for inference/evaluation/smoke and run-train for training startup, kickoff, or resume; direct execution is the default.
  4. Pause before fuller training or changes to dataset, split, checkpoint, preprocessing, metric, loss, model semantics, or interpretation.
  5. Award result-match only against explicit expected metrics and tolerance; process success alone is not reproduction success.
  6. Write the evidence bundle, return the requested bounded result, and stop; optional stages are not automatic follow-up work.

Patch Boundary

Prefer no repository edits. If edits are needed, keep them conservative and auditable:

  • Try command-line arguments, environment variables, path fixes, dependency version fixes, or dependency-file fixes before code changes.
  • Reproduction fixes are allowed when needed, but they must not be hidden. State what changed, why it was necessary, whether it changes scientific meaning, and whether it affects comparability with the paper, README, or baseline.
  • Avoid changing model architecture, core inference semantics, training logic, loss functions, or experiment meaning.
  • If repository files must change, create a branch named repro/YYYY-MM-DD-short-task, keep verified patch commits sparse, and record README-fidelity impact in PATCHES.md.

See references/patch-policy.md.

Outputs

Always target repro_outputs/:

SUMMARY.md
COMMANDS.md
LOG.md
SCIENTIFIC_CHANGELOG.md
COMPARABILITY_REPORT.md
status.json
ANNOTATED_README.md   # original README + colored per-section agent-action annotations
PATCHES.md   # only if patches were applied

Use the templates under assets/ and references/output-spec.md. Keep summaries short, commands copyable, machine state stable, and scientific/comparability changes explicit. ANNOTATED_README.md must preserve the source README byte-for-byte outside inserted evidence blocks and pass its strip/check round trip. Use --source-adjacent-readme only for an owned RIGORPILOT_README.md; never replace an unrelated file. Distinguish verified facts from inference.

Reference Loading

  • Workflow judgment: references/agent-operating-principles.md.
  • Human-readable output: references/language-policy.md.
  • Scientific/comparability judgment: references/research-rigor-principles.md and, when experiment details matter, references/deep-learning-experiment-principles.md.
  • Protocol-sensitive changes: references/research-safety-principles.md and references/patch-policy.md.
  • Personal rigor and lessons are advisory only; keep specialized detail in references/scripts rather than expanding this entrypoint.