bylllllllama· 44 skills
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.
$npx -y skills add lllllllama/rigorpilot-skills --skill ai-research-reproductionInstalls into the current project.
Run `npx skills use "https://github.com/lllllllama/rigorpilot-skills" --skill "lllllllama/rigorpilot-skills/ai-research-reproduction"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.
Use the skills in "https://github.com/lllllllama/rigorpilot-skills" that are relevant to the current task. Run `npx skills add "https://github.com/lllllllama/rigorpilot-skills"` and select the relevant skills, then follow their instructions.
| 1 | # ai-research-reproduction |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Use this as the Rigor Reproduce compatible skill slug for README-first deep |
| 6 | learning repository reproduction. The installed slug remains |
| 7 | `ai-research-reproduction` for compatibility. The skill guides the agent toward |
| 8 | a minimal trustworthy run with auditable evidence; it should not micromanage |
| 9 | implementation details that the model can infer from the repository. |
| 10 | Reproduction is not "make it run by changing anything"; it means faithfully |
| 11 | reading the README, environment, weights, datasets, and documented commands, |
| 12 | then recording results and deviations. |
| 13 | |
| 14 | Start from the shared operating principles in |
| 15 | `../../references/agent-operating-principles.md`, then load |
| 16 | `../../references/research-rigor-principles.md` and |
| 17 | `../../references/deep-learning-experiment-principles.md` when scientific meaning, comparability, or experiment details are at stake. |
| 18 | |
| 19 | ## Fit |
| 20 | |
| 21 | Use this skill when all are true: |
| 22 | |
| 23 | - The target is an AI code repository with a README, scripts, configs, or |
| 24 | documented commands. |
| 25 | - The request spans multiple trusted phases such as intake, setup, execution, |
| 26 | training verification, analysis, paper-gap resolution, and reporting. |
| 27 | - The desired result is a small reproducible target, not broad experimentation. |
| 28 | |
| 29 | Do not use this skill for paper summaries, generic environment setup, isolated |
| 30 | repo scanning, standalone command execution, open-ended research design, or |
| 31 | explicit candidate-only exploration. |
| 32 | |
| 33 | ## Trusted Target Selection |
| 34 | |
| 35 | Choose the smallest target that can honestly demonstrate repository-grounded |
| 36 | reproduction: |
| 37 | |
| 38 | 1. documented inference |
| 39 | 2. documented evaluation |
| 40 | 3. documented training startup or partial verification |
| 41 | 4. full training only after explicit user confirmation |
| 42 | |
| 43 | Treat README guidance as the primary reproduction intent. Use repository files |
| 44 | to clarify the README, not to silently replace it. When the README and paper |
| 45 | conflict, record the conflict and use `paper-context-resolver` only for the |
| 46 | narrow reproduction-critical gap. |
| 47 | |
| 48 | ## Workflow |
| 49 | |
| 50 | 1. Read the README and nearby repo signals. |
| 51 | 2. Use `repo-intake-and-plan` to extract documented commands and candidate |
| 52 | targets. |
| 53 | 3. Select and justify the minimum trustworthy target. |
| 54 | 4. Use `env-and-assets-bootstrap` only for target-specific environment, |
| 55 | checkpoint, dataset, and cache assumptions. |
| 56 | 5. Use `analyze-project` only when structure, insertion points, or suspicious |
| 57 | implementation patterns need read-only clarification. |
| 58 | 6. Use `minimal-run-and-audit` for documented inference, evaluation, smoke, or |
| 59 | sanity execution. |
| 60 | 7. Use `run-train` instead when the selected trusted target is training startup, |
| 61 | short-run verification, full kickoff, or resume. |
| 62 | 8. Pause for human review before fuller training claims or any change that could |
| 63 | alter dataset, split, checkpoint, preprocessing, metric, loss, model |
| 64 | semantics, or result interpretation. |
| 65 | 9. Write the standardized outputs and give a concise final note in the user's |
| 66 | language when practical. |
| 67 | |
| 68 | ## Patch Boundary |
| 69 | |
| 70 | Prefer no repository edits. If edits are needed, keep them conservative and |
| 71 | auditable: |
| 72 | |
| 73 | - Try command-line arguments, environment variables, path fixes, dependency |
| 74 | version fixes, or dependency-file fixes before code changes. |
| 75 | - Reproduction fixes are allowed when needed, but they must not be hidden. State |
| 76 | what changed, why it was necessary, whether it changes scientific meaning, |
| 77 | and whether it affects comparability with the paper, README, or baseline. |
| 78 | - Avoid changing model architecture, core inference semantics, training logic, |
| 79 | loss functions, or experiment meaning. |
| 80 | - If repository files must change, create a branch named |
| 81 | `repro/YYYY-MM-DD-short-task`, keep verified patch commits sparse, and record |
| 82 | README-fidelity impact in `PATCHES.md`. |
| 83 | |
| 84 | See `references/patch-policy.md`. |
| 85 | |
| 86 | ## Outputs |
| 87 | |
| 88 | Always target `repro_outputs/`: |
| 89 | |
| 90 | ```text |
| 91 | SUMMARY.md |
| 92 | COMMANDS.md |
| 93 | LOG.md |
| 94 | SCIENTIFIC_CHANGELOG.md |
| 95 | COMPARABILITY_REPORT.md |
| 96 | status.json |
| 97 | ANNOTATED_README.md # original README + colored per-section agent-action annotations |
| 98 | PATCHES.md # only if patches were applied |
| 99 | ``` |
| 100 | |
| 101 | Use the templates under `assets/` and the field rules in `references/output-spec.md`. |
| 102 | |
| 103 | - Put the shortest high-value summary in `SUMMARY.md`. |
| 104 | - Put copyable commands in `COMMANDS.md`. |
| 105 | - Put process evidence, assumptions, failures, and decisions in `LOG.md`. |
| 106 | - Put scientific meaning and change effects in `SCIENTIFIC_CHANGELOG.md`. |
| 107 | - Put comparison anchors and protocol deviations in `COMPARABILITY_REPORT.md`. |
| 108 | - Put durable machine-readable state in `status.json`. |
| 109 | - Put branch, commit, validation, and README-fidelity impact in `PATCHES.md` when needed. |
| 110 | - Put the researcher's at-a-glance view in `ANNOTATED_README.md`: the README replayed verbatim, each section annotated in color with what the agent did there, linked to the evidence files above. |
| 111 | - Distinguish verified facts from inferred guesses. |
| 112 | |
| 113 | ## Reference Loading |
| 114 | |
| 115 | - Load `references/language-policy.md` when writing human-readable outputs. |
| 116 | - Load `../../references/research-rigor-principles.md` before making |
| 117 | comparability, contribution, or research-result claims. |
| 118 | - Load `../../references/deep-learning-experiment-principles.md` when dataset, |
| 119 | split, metric, checkpoint, training, or evaluation details matter. |
| 120 | - Load `references/research-safety-principles.md` before protocol-sensitive |
| 121 | decisions. |
| 122 | - Load `references/patch-policy.md` before modifying repository files. |
| 123 | - Keep specialized logic in sub-skills, scripts, templates, or references rather |
| 124 | than expanding this entrypoint. |