--- name: lllllllama-rigorpilot-skills title: rigorpilot skills kind: skill-folder description: 11 skills kept together in one folder, by Chengkun Rao. skills: 11 updated: 2026-10-12 authored_by: Chengkun Rao source_url: https://github.com/lllllllama/rigorpilot-skills page: https://innernet.live/community/skills/lllllllama/rigorpilot-skills --- # rigorpilot skills a folder of 11 skills by Chengkun Rao, kept on innernet at https://innernet.live/community/skills/lllllllama/rigorpilot-skills (source: https://github.com/lllllllama/rigorpilot-skills). every skill in it is below, whole. each one starts with its own manifest: what it does, when to load it, whose it is. you do not need all of them at once. read the index, then use the skill that fits the task in front of you. each skill also has its own link, if only one is wanted. ## the skills 1. **ai research explore**: Rigor Explore compatible skill slug for meaningful and potentially novel deep learning research candidates. Use when the researcher has chosen the task family, dataset, benchmark, evaluation method, provided SOTA references, and wants candidate-only exploration on top of `current_research` with auditable repo understanding, idea gating, fair comparison, and governed experiments written to `explore_outputs/`. Do not use for README-first trusted reproduction, open-ended direction finding, narrow code-only or run-only exploration, passive repo analysis, verified novelty claims, or implicit experi https://innernet.live/skills/lllllllama-ai-research-explore 2. **ai research reproduction**: 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 se https://innernet.live/skills/lllllllama-ai-research-reproduction 3. **analyze project**: Rigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrypoints, review configs and insertion points, or flag suspicious implementation patterns without modifying code or running heavy jobs. Do not use for active command execution, broad refactoring, speculative code adaptation, or automatic bug fixing. https://innernet.live/skills/lllllllama-analyze-project 4. **env and assets bootstrap**: Rigor Setup skill for README-first deep learning repo reproduction. Use when the task is specifically to prepare a conservative conda-first environment, checkpoint and dataset path assumptions, cache location hints, and setup notes before any run on a README-documented repository. Do not use for repo scanning, full orchestration, paper interpretation, final run reporting, or generic environment setup that is not tied to a specific reproduction target. https://innernet.live/skills/lllllllama-env-and-assets-bootstrap 5. **explore code**: Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or defa https://innernet.live/skills/lllllllama-explore-code 6. **explore run**: Rigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subset validation, short-cycle guess-and-check, batch sweeps, idle-GPU search, or quick transfer-learning trials, with fair-comparison caveats and no-overclaim summaries in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline execution, conservative training verification, default routing, verified SOTA claims, or implicit experimentation https://innernet.live/skills/lllllllama-explore-run 7. **minimal run and audit**: Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized `repro_outputs/` files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself. https://innernet.live/skills/lllllllama-minimal-run-and-audit 8. **paper context resolver**: Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default. https://innernet.live/skills/lllllllama-paper-context-resolver 9. **repo intake and plan**: Rigor Intake helper for README-first deep learning repo reproduction. Use when the task is specifically to scan a repository, read the README and common project files, extract documented commands, classify inference, evaluation, and training candidates, and return the smallest trustworthy reproduction plan to the main orchestrator. Do not use for environment setup, asset download, command execution, final reporting, paper lookup, or end-to-end orchestration. https://innernet.live/skills/lllllllama-repo-intake-and-plan 10. **run train**: Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized `train_outputs/`. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration. https://innernet.live/skills/lllllllama-run-train 11. **safe debug**: Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization. https://innernet.live/skills/lllllllama-safe-debug --- --- name: lllllllama-ai-research-explore title: ai research explore kind: skill description: > Rigor Explore compatible skill slug for meaningful and potentially novel deep learning research candidates. Use when the researcher has chosen the task family, dataset, benchmark, evaluation method, provided SOTA references, and wants candidate-only exploration on top of `current_research` with auditable repo understanding, idea gating, fair comparison, and governed experiments written to `explore_outputs/`. Do not use for README-first trusted reproduction, open-ended direction finding, narrow code-only or run-only exploration, passive repo analysis, verified novelty claims, or implicit experi updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/ai-research-explore brought_by: kt license: MIT --- # ai-research-explore ## Purpose Use this as the Rigor Explore compatible skill slug after the researcher explicitly authorizes candidate-only work on top of a durable `current_research` anchor. The installed slug remains `ai-research-explore` for compatibility. Rigor Explore is for meaningful and potentially novel deep learning research candidates while preserving scientific rigor, comparability, reproducibility, and auditable collaboration. Novelty and significance remain hypotheses before literature contrast, ablation evidence, and fair comparison. The skill does not promise autonomous discovery, global benchmark completeness, novelty proof, or trusted reproduction success. Start from the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`, then load `../ai-research-reproduction/references/research-rigor-principles.md` for research claims and `../ai-research-reproduction/references/deep-learning-experiment-principles.md` when experiment details affect comparability or reproducibility. ## Fit Use this skill only when the request has both: - Explicit exploration authorization such as candidate-only work, isolated branch or worktree, sweep, several variants, or exploratory ranking. - A durable `current_research` context such as a branch, commit, checkpoint, run record, or already-trained local model state. Keep narrow code-only requests on `explore-code`. Keep narrow run-only requests on `explore-run`. Keep passive repository analysis on `analyze-project`. Keep README-first reproduction on `ai-research-reproduction`. ## Research Rhythm Use a two-loop rhythm: - Outer loop: understand the repository, freeze task/dataset/evaluation/budget, preserve user ideas, map sources, gate ideas, and decide whether the next experiment is worth running. - Inner loop: make one bounded candidate change or run, smoke-check it, collect evidence, rank it against the current anchor, and either stop or return to the outer loop with the new evidence. This rhythm is a guide, not a rigid autonomous loop. Stop at explicit blockers, unclear scientific meaning, exhausted budget, missing anchor/evaluation, or a human checkpoint. ## Workflow 1. Confirm `current_research` and explicit explore-lane authorization. 2. Accept either legacy `variant_spec` or higher-level `research_campaign`. 3. In campaign mode, freeze the task, dataset, benchmark, evaluation source, SOTA reference, and budget before candidate work. 4. Build only the repo-understanding artifacts needed for the current campaign, usually through `analyze-project`. 5. Run bounded, cache-first source lookup when source support matters; prefer local curated literature such as Zotero if available, then seed sources, repo-local locators, public locators, or optional web lookup. Treat lookup as source resolution, not an open-ended literature search. 6. Preserve researcher-provided ideas, optionally add a small bounded set of single-variable seed ideas, and rank ideas with explicit gates and score breakdowns. 7. Prefer one clear candidate at a time. Use `explore-code` for bounded code adaptation and `explore-run` for short-cycle trials or sweeps. 8. Use `minimal-run-and-audit` or `run-train` only when the exploratory plan requires real execution evidence. 9. Write candidate-only outputs to `analysis_outputs/`, `sources/`, and `explore_outputs/` as appropriate; never present exploratory gains as trusted reproduction success. Include `SCIENTIFIC_CHANGELOG.md` and `COMPARABILITY_REPORT.md` for candidate scientific meaning and comparison boundaries. ## Ranking and Evidence - Before execution, prioritize candidates by expected gain, cost, success likelihood, patch surface, dependency drag, evaluation risk, and rollback ease. - After execution, rank by real evidence first: command status, observed metrics, artifacts, changed paths, smoke results, and reproducibility notes. - Keep researcher-provided `evaluation_source` and `sota_reference` frozen for the campaign; do not claim they are globally complete. - If the top ideas are too close or the implementation cannot be decomposed into auditable units, stop for a checkpoint instead of silently choosing. ## Campaign Inputs `research_campaign` is preferred for Rigor Explore campaigns, but it should stay minimal. The durable core is: - `current_research` - `task_family` - `dataset` - `benchmark` - `evaluation_source` - `sota_reference` - `compute_budget` Use `candidate_ideas`, `variant_spec`, `research_lookup`, `idea_policy`, `idea_generation`, `source_constraints`, `feasibility_policy`, `baseline_gate`, and `execution_policy` as optional guidance, not as fields the agent must fill for every campaign. See `references/research-campaign-spec.md` for the advanced schema and artifact expectations. ## Reference Loading - Load `references/ai-research-explore-policy.md` for lane safety and candidate semantics. - Load `references/research-campaign-spec.md` only when a campaign file is present or the user asks for Rigor Explore campaign governance. - Load `../ai-research-reproduction/references/explore-variant-spec.md` for run-level variant matrix details. - Load `../ai-research-reproduction/references/research-thinking-loop.md` before proposing or ranking candidate changes; it is the required greedy observe-ground-design-compare cycle. - Load `../ai-research-reproduction/references/research-rigor-principles.md` before making novelty, contribution, SOTA, or comparability statements. - Consult `~/.rigorpilot/PERSONAL_RIGOR.md` if present, under `../ai-research-reproduction/references/continuous-learning-policy.md` (advisory only; core wins). - Load `../ai-research-reproduction/references/deep-learning-experiment-principles.md` when training, evaluation, baseline, ablation, metric, checkpoint, or dataset details matter. - Use `scripts/orchestrate_explore.py` and `scripts/write_outputs.py` for the existing deterministic artifact workflow. --- --- name: lllllllama-ai-research-reproduction title: ai research reproduction kind: skill 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 se updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/ai-research-reproduction brought_by: kt license: MIT --- # 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 --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 `/repro_outputs` regardless of caller cwd. 3. Run the selected candidate, or another reviewed candidate, with `--run-selected --command-id --plan-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//`. ## 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/`: ```text 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. --- --- name: lllllllama-analyze-project title: analyze project kind: skill description: > Rigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrypoints, review configs and insertion points, or flag suspicious implementation patterns without modifying code or running heavy jobs. Do not use for active command execution, broad refactoring, speculative code adaptation, or automatic bug fixing. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/analyze-project brought_by: kt license: MIT --- # analyze-project Use this as the Rigor Analyze / Rigor Audit read-only skill. The installed slug remains `analyze-project` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should guide read-only analysis without constraining the model's project-specific reasoning. ## When to apply - The user wants to understand a deep learning repository before changing it. - The user needs a map of model structure, training entrypoints, inference entrypoints, and config relationships. - The user wants conservative suggestions about likely insertion points or suspicious implementation patterns. - The user explicitly wants read-only analysis and not heavy execution. ## When not to apply - When the main task is to execute a failing command or debug a traceback. - When the user wants environment setup or asset download only. - When the user wants speculative adaptation or broad exploratory patching. - When the task is a general literature summary without repository analysis. ## Clear boundaries - This skill is read-mostly. - It may run lightweight static inspection helpers. - It does not patch repository code. - It does not own final reproduction outputs. - It should mark suspicious patterns as heuristics, not confirmed bugs. ## Output expectations - `analysis_outputs/SUMMARY.md` - `analysis_outputs/RISKS.md` - `analysis_outputs/status.json` ## Notes Use `references/analysis-policy.md` and the shared `../ai-research-reproduction/references/research-pitfall-checklist.md`. --- --- name: lllllllama-env-and-assets-bootstrap title: env and assets bootstrap kind: skill description: > Rigor Setup skill for README-first deep learning repo reproduction. Use when the task is specifically to prepare a conservative conda-first environment, checkpoint and dataset path assumptions, cache location hints, and setup notes before any run on a README-documented repository. Do not use for repo scanning, full orchestration, paper interpretation, final run reporting, or generic environment setup that is not tied to a specific reproduction target. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/env-and-assets-bootstrap brought_by: kt license: MIT --- # env-and-assets-bootstrap Use this as the Rigor Setup skill. The installed slug remains `env-and-assets-bootstrap` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should keep setup planning conservative while leaving environment-specific judgment to the model. ## When to apply - After repo intake identifies a credible reproduction target. - When environment creation or asset path preparation is needed before running commands. - When the repo depends on checkpoints, datasets, or cache directories. - When the user explicitly wants setup help before any run attempt. ## When not to apply - When the repository already ships a ready-to-run environment that does not need translation. - When the task is only to scan and plan. - When the task is only to report results from commands that already ran. - When the request is a generic conda or package-management question outside repo reproduction. ## Clear boundaries - This skill prepares environment and asset assumptions. - It does not own target selection. - It does not own final reporting. - It does not perform paper lookup except by forwarding gaps to the optional paper resolver. ## Input expectations - target repo path - selected reproduction goal - relevant README setup steps - any known OS or package constraints ## Output expectations - conservative environment setup notes - candidate conda commands - asset path plan - checkpoint and dataset source hints - unresolved dependency or asset risks ## Notes Use `references/env-policy.md`, `references/assets-policy.md`, `scripts/bootstrap_env.py`, `scripts/plan_setup.py`, and `scripts/prepare_assets.py`. Use `scripts/bootstrap_env.sh` only as a POSIX wrapper around the Python bootstrapper when a shell entrypoint is more convenient. --- --- name: lllllllama-explore-code title: explore code kind: skill description: > Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or defa updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/explore-code brought_by: kt license: MIT --- # explore-code Use this as the Rigor Improve implementation leaf skill. The installed slug remains `explore-code` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should guide bounded candidate code work without over-prescribing implementation details. ## When to apply - When the researcher explicitly authorizes exploratory code changes on an isolated branch or worktree. - When the task is source-anchored module transplant, backbone adaptation, LoRA or adapter insertion, or low-risk module combination. - When summary-level recording is sufficient and the result is a candidate, not a trusted conclusion. ## When not to apply - When the request is for trusted baseline work, conservative debugging, or normal training execution. - When the user did not explicitly authorize exploratory modifications. - When the task is a broad refactor or a from-scratch idea implementation. ## Clear boundaries - This skill owns exploratory code modifications only. - It must keep work isolated from the trusted baseline. - Use `ai-research-explore` instead when the task spans both current_research coordination and exploratory runs. - It may hand off execution to `minimal-run-and-audit` or `run-train`. - It should favor source-anchored copying and minimal adaptation over freeform rewrites. - It should record why a candidate change is meaningful, how to roll it back, and why it remains a candidate rather than a verified contribution. ## Output expectations - `explore_outputs/CHANGESET.md` - `explore_outputs/SCIENTIFIC_CHANGELOG.md` - `explore_outputs/COMPARABILITY_REPORT.md` - `explore_outputs/TOP_RUNS.md` - `explore_outputs/status.json` ## Notes Use `references/explore-policy.md`, `../ai-research-reproduction/references/research-rigor-principles.md`, `scripts/plan_code_changes.py`, and `scripts/write_outputs.py`. --- --- name: lllllllama-explore-run title: explore run kind: skill description: > Rigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subset validation, short-cycle guess-and-check, batch sweeps, idle-GPU search, or quick transfer-learning trials, with fair-comparison caveats and no-overclaim summaries in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline execution, conservative training verification, default routing, verified SOTA claims, or implicit experimentation updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/explore-run brought_by: kt license: MIT --- # explore-run Use this as the Rigor Improve / Rigor Explore run leaf skill. The installed slug remains `explore-run` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should guide candidate run planning while preserving model judgment about the active repo. ## When to apply - When the researcher explicitly authorizes exploratory runs. - When the task is a small-subset validation, short-cycle training probe, batch sweep, idle-GPU search, or quick transfer-learning trial. - When the output should rank candidate runs rather than certify trusted success. ## When not to apply - When the user wants trusted training execution or conservative verification. - When there is no explicit exploratory authorization. - When the task is repository setup, intake, or debugging. ## Clear boundaries - This skill owns exploratory execution planning and summary only. - Use `ai-research-explore` instead when the task spans both current_research coordination and exploratory code changes. - It may hand off actual command execution to `minimal-run-and-audit` or `run-train`. - It should keep experiment state isolated from the trusted baseline. - It should prefer small-subset and short-cycle checks before heavier exploratory runs. - It should label run results as bounded evidence and explain when a comparison is not directly fair. ## Ranking Semantics - Pre-execution candidate selection uses three factors: `cost`, `success_rate`, and `expected_gain`. - Default weights should stay conservative unless the researcher explicitly provides `selection_weights`. - Budget pruning still applies after scoring through `max_variants` and `max_short_cycle_runs`. - If runs are executed later, downstream ranking should switch to real execution evidence, not stay purely heuristic. ## Variant Spec Hints - Use `variant_axes` to define the candidate dimension grid. - Use `subset_sizes` and `short_run_steps` to express exploratory run scale. - Use `selection_weights` to rebalance `cost`, `success_rate`, and `expected_gain`. - Use `primary_metric` and `metric_goal` so downstream ranking can order executed candidates consistently. ## Output expectations - `explore_outputs/CHANGESET.md` - `explore_outputs/SCIENTIFIC_CHANGELOG.md` - `explore_outputs/COMPARABILITY_REPORT.md` - `explore_outputs/TOP_RUNS.md` - `explore_outputs/status.json` ## Notes Use `references/execution-policy.md`, `../ai-research-reproduction/references/explore-variant-spec.md`, `../ai-research-reproduction/references/deep-learning-experiment-principles.md`, `scripts/plan_variants.py`, and `scripts/write_outputs.py`. --- --- name: lllllllama-minimal-run-and-audit title: minimal run and audit kind: skill description: > Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized `repro_outputs/` files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/minimal-run-and-audit brought_by: kt license: MIT --- # minimal-run-and-audit Use this as the Rigor Run skill. The installed slug remains `minimal-run-and-audit` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should make run evidence auditable without turning every command into a rigid protocol. ## When to apply - After a reproduction target and setup plan exist. - When the main skill needs execution evidence and normalized outputs. - When a smoke test, documented inference run, documented evaluation run, or other short non-training verification is appropriate. - When the user already knows what command should be attempted and wants execution plus reporting only. ## When not to apply - During initial repo scanning. - When environment or assets are still undefined enough to make execution meaningless. - When the task is a literature lookup rather than repository execution. - When the user is still deciding which reproduction target should count as the main run. ## Clear boundaries - This skill owns normalized reporting for an attempted command. - It may receive execution evidence from the main skill or a thin helper. - It does not choose the overall target on its own. - It does not perform broad paper analysis. - It does not own training startup, resume, or long-running training state. - It should not normalize risky code edits into acceptable practice. - It must not hide changes that alter evaluation, preprocessing, checkpoints, metrics, or other scientific meaning. ## Input expectations - selected reproduction goal - runnable commands or smoke commands - environment and asset assumptions - optional patch metadata ## Output expectations - execution result summary - standardized `repro_outputs/` files - `SCIENTIFIC_CHANGELOG.md` for changed scientific meaning and evidence status - `COMPARABILITY_REPORT.md` for README/paper/baseline comparability - clear distinction between verified, partial, and blocked states - `PATCHES.md` when repo files changed ## Notes Use `references/reporting-policy.md`, `../ai-research-reproduction/references/research-rigor-principles.md`, `scripts/run_command.py`, and `scripts/write_outputs.py`. --- --- name: lllllllama-paper-context-resolver title: paper context resolver kind: skill description: > Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/paper-context-resolver brought_by: kt license: MIT --- # paper-context-resolver Use this as the Rigor Paper Context helper. The installed slug remains `paper-context-resolver` for compatibility. ## When to apply - README and repo files leave a reproduction-critical gap. - The gap concerns dataset version, split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumptions. - The main skill needs a narrow evidence supplement instead of a full paper summary. - There is already a concrete reproduction question to answer. ## When not to apply - The README already gives enough reproduction detail. - The user wants a general paper explanation rather than reproduction support. - The goal is to override README instructions without documenting the conflict. - The only available input is a paper title and there is no concrete reproduction gap yet. ## Clear boundaries - This skill is optional. - This skill is helper-tier and should usually be orchestrator-invoked. - It supplements README-first reproduction. - It does not replace the main orchestration flow. - It does not summarize the whole paper by default. ## Input expectations - target repo metadata - reproduction-critical question - existing README or repo evidence - any already known paper links ## Output expectations - narrowed source list - reproduction-relevant answer only - explicit README-paper conflict note when applicable - clear distinction between direct evidence and inference ## Notes Use `references/paper-assisted-reproduction.md`. --- --- name: lllllllama-repo-intake-and-plan title: repo intake and plan kind: skill description: > Rigor Intake helper for README-first deep learning repo reproduction. Use when the task is specifically to scan a repository, read the README and common project files, extract documented commands, classify inference, evaluation, and training candidates, and return the smallest trustworthy reproduction plan to the main orchestrator. Do not use for environment setup, asset download, command execution, final reporting, paper lookup, or end-to-end orchestration. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/repo-intake-and-plan brought_by: kt license: MIT --- # repo-intake-and-plan Use this as the Rigor Intake helper. The installed slug remains `repo-intake-and-plan` for compatibility. ## When to apply - At the beginning of README-first reproduction work. - When the main skill needs a fast map of repo structure and documented commands. - When inference, evaluation, and training candidates must be classified conservatively. - When the user explicitly wants to inspect the repo first and not run anything yet. ## When not to apply - When execution has already started and the task is now about running commands or writing outputs. - When the target is not a repository-backed reproduction task. - When the user only wants paper interpretation without repo inspection. - When the user already has a selected documented command and only needs setup or execution. ## Clear boundaries - This skill scans and plans. - This skill is helper-tier and should usually be orchestrator-invoked. - It does not install environments. - It does not prepare large assets. - It does not execute substantive reproduction commands. - It does not decide high-risk patching. ## Input expectations - Target repository path. - Access to README and common project files if present. - Optional user hints about desired priority, such as inference-first. ## Output expectations - concise repo structure summary - documented command inventory - inferred candidate categories: inference, evaluation, training, other - minimum trustworthy reproduction recommendation - notable ambiguity or risk list ## Notes Use `references/repo-scan-rules.md` and helper scripts under `scripts/`. --- --- name: lllllllama-run-train title: run train kind: skill description: > Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized `train_outputs/`. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/run-train brought_by: kt license: MIT --- # run-train Use this as the Rigor Train skill. The installed slug remains `run-train` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should keep training evidence bounded while leaving repository-specific monitoring details to the model. ## When to apply - When the training command has already been selected and should be executed conservatively. - When the researcher wants startup verification, short-run verification, full training kickoff, or resume handling. - When the run needs structured training status, checkpoint, and metric reporting. ## When not to apply - When the main task is environment setup or asset download. - When the researcher wants inference-only or evaluation-only execution. - When the task is speculative exploration, multi-variant sweeps, or autonomous idea implementation. - When the user still needs repository intake or paper gap resolution. ## Clear boundaries - This skill executes a selected training command and normalizes the resulting evidence. - It does not choose the overall research goal on its own. - It does not own exploratory branching or speculative code adaptation. - It should record partial, blocked, resumed, and kicked-off states clearly. - It should preserve reproducibility context such as configs, seeds, checkpoints, logs, metrics, and runtime assumptions when available. ## Input expectations - selected training goal - runnable training command - environment and asset assumptions - run mode such as startup verification, short-run verification, full kickoff, or resume ## Output expectations - `train_outputs/SUMMARY.md` - `train_outputs/COMMANDS.md` - `train_outputs/LOG.md` - `train_outputs/SCIENTIFIC_CHANGELOG.md` - `train_outputs/COMPARABILITY_REPORT.md` - `train_outputs/status.json` ## Notes Use `references/training-policy.md`, `../ai-research-reproduction/references/deep-learning-experiment-principles.md`, `scripts/run_training.py`, and `scripts/write_outputs.py`. --- --- name: lllllllama-safe-debug title: safe debug kind: skill description: > Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization. updated: 2026-10-12 authored_by: Chengkun Rao author_url: https://github.com/lllllllama source_url: https://github.com/lllllllama/rigorpilot-skills/tree/main/skills/safe-debug brought_by: kt license: MIT --- # safe-debug Use this as the Rigor Debug / Rigor Audit skill. The installed slug remains `safe-debug` for compatibility. Use the shared operating principles in `../ai-research-reproduction/references/agent-operating-principles.md`; this skill should guide conservative diagnosis without blocking the model from finding the local root cause. ## When to apply - The user provides a traceback, terminal error, or concrete training or inference failure symptom. - The user wants diagnosis, root-cause narrowing, and minimal patch suggestions before code is changed. - The user wants a safe debug flow with explicit human approval before mutation. ## When not to apply - When the user wants a broad repository walkthrough without an active failure. - When the task is speculative experimentation or code adaptation. - When the user is asking for a large refactor or readability rewrite. ## Clear boundaries - Diagnose first. - Do not modify repository code by default. - If a patch is needed, propose the smallest fix and require explicit approval first. - Escalate savepoint or branch creation before medium-risk or high-risk changes. - A debug fix is not automatically a research contribution; if it changes experiment meaning or comparability, say so explicitly. ## Output expectations - `debug_outputs/DIAGNOSIS.md` - `debug_outputs/PATCH_PLAN.md` - `debug_outputs/status.json` ## Notes Use `references/debug-policy.md`, `../ai-research-reproduction/references/research-rigor-principles.md`, and the shared `../ai-research-reproduction/references/research-pitfall-checklist.md`.