AutoSciRub
Purpose
Use this skill as the top-level controller for the AutoSciRub method:
- Rubric Skeleton Induction
- Scientific Literature Grounding
- Task-Data Exploration
- Criterion Synthesis
- Rubric-guided execution by the current research agent
- Criterion-Level Verification
- Targeted Revision
AutoSciRub creates a task-specific executable rubric at inference time, then uses it as an execution and verification contract.
State Contract
Use the current project as the task root. Resolve the state directory once: explicit user choice, then AUTOSCIRUB_STATE_DIR, then state_dir in project .autoscirub/config.yaml, then .autoscirub/. All relative paths are relative to the research project. Throughout this skill and its child skills, replace .autoscirub/ output paths with that resolved directory.
Expected files:
.autoscirub/
run_manifest.json
rubric_skeleton.json
literature_sources.json # when bundled retrieval is used
literature_grounding.json
task_data_profile.json
executable_rubric.json
verification_report.json
revisions/
round-001/
verification.json
revision_plan.json
change_summary.json
Do not assume fixed paths such as INSTRUCTIONS.md, data/, outputs/, or report/. If those files exist, use them. Otherwise use the task text, user-specified paths, and discoverable project files.
Inputs
Collect these inputs when available:
- research instruction from the user or an instruction file
- optional
.autoscirub/config.yaml or user-provided config
- task-visible literature, data, code, tools, and prior artifacts
- optional benchmark profile that declares hidden-file exclusions, blocklists, or output conventions
Treat profiles as constraints injected by the harness, not as built-in assumptions.
Workflow
- Establish the user’s requested boundary (rubric only, verification only, or execution). Reuse valid artifacts for the same task; do not regenerate them just because the workflow starts here. At the start and end, write
run_manifest.json with task summary, resolved state directory, requested boundary, current stage, status (running, completed, blocked, or budget_exhausted), revision limit, completed rounds, and artifact paths. Treat this as a progress record, not proof that outputs are valid.
- Run
rubric-skeleton-induction using only the instruction. Write .autoscirub/rubric_skeleton.json.
- Run
scientific-literature-grounding using the skeleton and task-visible literature/search. Write .autoscirub/literature_grounding.json.
- Run
task-data-exploration using lightweight inspection of visible data and tools. Write .autoscirub/task_data_profile.json.
- Run
criterion-synthesis to combine goals, literature grounding, and data feasibility. Write .autoscirub/executable_rubric.json.
- Execute the research task against the executable rubric. Produce the report and supporting code/results in project-appropriate locations.
- Run
criterion-level-verification against the current artifact. Write .autoscirub/verification_report.json or a round-specific verification file.
- For an authorized full workflow, use the user’s revision limit or
workflow.max_revision_rounds (default 1). After each targeted-revision round, rerun verification on the changed artifacts. Stop when all criteria pass, the budget is exhausted, or remaining gaps need unavailable inputs. Standalone verification never authorizes revision.
Execution Rules
- Keep the rubric explicit and evidence-oriented. Each criterion should be verifiable against artifacts.
- Use literature to design scientific evidence, not as a substitute for task-generated evidence.
- Use lightweight data exploration during induction; defer full experiments to execution.
- Do not invent labels, measurements, target values, hidden files, or unavailable resources.
- Do not hard-code virtual environments, dependency managers, API providers, model names, or machine paths.
- Use the user's active environment and agent-native tools unless the user provides a different setup.
- Tell the user which stage is running and where its results are saved. At handoff, name the report, evidence, failed criteria, and next actionable step.
- For a small task, keep goals and criteria correspondingly small; numerical size suggestions in child skills are not quotas.
- Stop after the requested boundary: induction only, execution only, verification only, or one revision round.
Completion Criteria
For rubric-only work, completion is the requested rubric artifact. For verification-only work, completion is a truthful verification report, even if criteria fail. For full execution, report success only when all in-scope criteria pass; budget exhaustion or missing inputs must remain explicit and must not be relabelled as scientific success.
1---2name: autoscirub3description: Coordinate the full AutoSciRub workflow for autonomous scientific research tasks. Use when a user wants to turn an underspecified research instruction into an executable rubric, guide research execution, verify a report criterion by criterion, and run targeted revision rounds across Codex, Claude Code, OpenClaw, or another agent harness.4---56# AutoSciRub78## Purpose910Use this skill as the top-level controller for the AutoSciRub method:11121. Rubric Skeleton Induction132. Scientific Literature Grounding143. Task-Data Exploration154. Criterion Synthesis165. Rubric-guided execution by the current research agent176. Criterion-Level Verification187. Targeted Revision1920AutoSciRub creates a task-specific executable rubric at inference time, then uses it as an execution and verification contract.2122## State Contract2324Use the current project as the task root. Resolve the state directory once: explicit user choice, then `AUTOSCIRUB_STATE_DIR`, then `state_dir` in project `.autoscirub/config.yaml`, then `.autoscirub/`. All relative paths are relative to the research project. Throughout this skill and its child skills, replace `.autoscirub/` output paths with that resolved directory.2526Expected files:2728```text29.autoscirub/30 run_manifest.json31 rubric_skeleton.json32 literature_sources.json # when bundled retrieval is used33 literature_grounding.json34 task_data_profile.json35 executable_rubric.json36 verification_report.json37 revisions/38 round-001/39 verification.json40 revision_plan.json41 change_summary.json42```4344Do not assume fixed paths such as `INSTRUCTIONS.md`, `data/`, `outputs/`, or `report/`. If those files exist, use them. Otherwise use the task text, user-specified paths, and discoverable project files.4546## Inputs4748Collect these inputs when available:4950- research instruction from the user or an instruction file51- optional `.autoscirub/config.yaml` or user-provided config52- task-visible literature, data, code, tools, and prior artifacts53- optional benchmark profile that declares hidden-file exclusions, blocklists, or output conventions5455Treat profiles as constraints injected by the harness, not as built-in assumptions.5657## Workflow58590. Establish the user’s requested boundary (rubric only, verification only, or execution). Reuse valid artifacts for the same task; do not regenerate them just because the workflow starts here. At the start and end, write `run_manifest.json` with task summary, resolved state directory, requested boundary, current stage, status (`running`, `completed`, `blocked`, or `budget_exhausted`), revision limit, completed rounds, and artifact paths. Treat this as a progress record, not proof that outputs are valid.601. Run `rubric-skeleton-induction` using only the instruction. Write `.autoscirub/rubric_skeleton.json`.612. Run `scientific-literature-grounding` using the skeleton and task-visible literature/search. Write `.autoscirub/literature_grounding.json`.623. Run `task-data-exploration` using lightweight inspection of visible data and tools. Write `.autoscirub/task_data_profile.json`.634. Run `criterion-synthesis` to combine goals, literature grounding, and data feasibility. Write `.autoscirub/executable_rubric.json`.645. Execute the research task against the executable rubric. Produce the report and supporting code/results in project-appropriate locations.656. Run `criterion-level-verification` against the current artifact. Write `.autoscirub/verification_report.json` or a round-specific verification file.667. For an authorized full workflow, use the user’s revision limit or `workflow.max_revision_rounds` (default 1). After each `targeted-revision` round, rerun verification on the changed artifacts. Stop when all criteria pass, the budget is exhausted, or remaining gaps need unavailable inputs. Standalone verification never authorizes revision.6768## Execution Rules6970- Keep the rubric explicit and evidence-oriented. Each criterion should be verifiable against artifacts.71- Use literature to design scientific evidence, not as a substitute for task-generated evidence.72- Use lightweight data exploration during induction; defer full experiments to execution.73- Do not invent labels, measurements, target values, hidden files, or unavailable resources.74- Do not hard-code virtual environments, dependency managers, API providers, model names, or machine paths.75- Use the user's active environment and agent-native tools unless the user provides a different setup.76- Tell the user which stage is running and where its results are saved. At handoff, name the report, evidence, failed criteria, and next actionable step.77- For a small task, keep goals and criteria correspondingly small; numerical size suggestions in child skills are not quotas.78- Stop after the requested boundary: induction only, execution only, verification only, or one revision round.7980## Completion Criteria8182For rubric-only work, completion is the requested rubric artifact. For verification-only work, completion is a truthful verification report, even if criteria fail. For full execution, report success only when all in-scope criteria pass; budget exhaustion or missing inputs must remain explicit and must not be relabelled as scientific success.