Optimize learning per unit of time. Start with one fast, revealing task,\nplan competing hypotheses, test them separately, combine verified winners, then\nexpand coverage. The durable result is a parameter-effect map plus the best\nverified artifact. An experiment is a checkpoint, not a stopping point.
\nRecover the research state. Read the objective, user feedback, project\ninstructions, and existing research records. Reconcile the handoff with actual\nartifacts and running jobs; collect a pending attempt before launching another.\nIdentify the best verified artifact (the incumbent), active task, regression\nset, hypothesis queue, and remaining budget. Reuse existing record locations.
\nClarify success before experimenting. Recover any already agreed criteria;\ndo not ask the user to repeat them. If the evaluator, metric, comparison\nbaseline, or required improvement is unclear, ask focused questions and wait\nfor answers before editing candidates or launching evaluations. Inspect\nexisting artifacts and propose concrete options to make answering easier;\ndo not silently choose what success means. Continue clarification until the\nanswers define a checkable criterion, including evaluation scope, aggregation,\nand non-regression gates. Restate that criterion in the research contract.
\nDistinguish passing correctness gates from achieving the optimization target.\nSpecify whether the target is an absolute score, an absolute change, or a\nrelative improvement against a named baseline. “Improve accuracy by 5%” is\nambiguous: from 60%, five percentage points means 65%, while 5% relative means\n63%. Clarify the units and direction; record the formula when needed. A\nbaseline's value may be measured next, but its identity and the comparison rule\nmust be settled first. Accept open-ended optimization only when that is the\nuser's intent; do not invent a threshold or substitute any improvement for\nthe requested improvement.
\nThen define the smallest useful loop. Record mutable parameters and the\nfixed evaluator and select one cheap task that exposes the behavior being\nimproved. Measure its turnaround and remove\nunnecessary setup, models, cases, and implementation work from the inner loop.\nPrefer an architectural spike when the uncertainty is architectural.\nAvailable benchmark tasks are a pool, not a requirement to run them all;\nchoose validation coverage to support the intended claim and user's scope.
\nRecord the evaluation command, timeout, repair allowance, resource limits,\npromotion rule, and confirmation plan. Separate research spend from the cost\nor runtime being optimized. Done means the success criterion is resolved and\nthe next trial is cheap to run with an unambiguous decision rule; do not build\na large benchmark matrix before testing the first hypothesis.
\nEstablish the active task's baseline. Run the unchanged artifact once, or\nreuse its compatible recorded result and traces. Verify the evaluator measures\nthe intended outcome; use a known failing control if detection is unproven.\nKeep the baseline fixed for this task/model/harness; do not rerun it per variant.\nFor noisy measurements, plan only the repeats needed to distinguish an effect,\nrespecting any user instruction to reuse a single baseline and reporting that\nlimitation. Save exact inputs, artifact identity, and raw output.
\nPlan a small hypothesis batch. Before editing, list distinct explanations\nof the current bottleneck and the parameters or strategies that could test\nthem. Inspect actual failure traces and matched baseline behavior instead of\nguessing from aggregate scores. For each hypothesis, record:
\nRank by information gained per unit of time. Test alternatives one by one\nagainst the same parent so their effects remain interpretable. Avoid exhaustive\nparameter grids. Keep the queue short and revise it after results; planning\nis part of every research cycle, not a one-time backlog or a reason to delay\nthe first trial.
\nTest one hypothesis on the active task. Preserve the incumbent and isolate\nthe candidate from unrelated work. Change one conceptual factor; if a coupled\nbundle is necessary, attribute the result to that bundle. Record the candidate\nidentity and prediction before running. Use cheap checks first, then the\nfocused task; do not run the broad suite for every variant. Save uniquely\nidentified raw output and inspect relevant traces. Bound crashes and repairs;\na repaired candidate gets a new identity. Missing results are unknown, not zero.
\nCompare observation with prediction, including regressions and null results.\nRecord keep, discard, inconclusive, or invalid and update the map.\nRestore the parent between alternatives; retain reproducible snapshots or\npatches and evidence outside rollback scope. Rejecting a candidate does not\ndisprove its entire strategy: diagnose a promising partial win and plan a\ntargeted follow-up when evidence supports one.
Combine and promote. Test compatible winners together against the strongest\nindividual candidate. Do not assume gains add: check interactions, and remove\none change at a time when attribution is unclear. A combination that loses\nto a simpler candidate does not become the incumbent.
\nA focused win is provisional. Before promotion, check the candidate against\npreviously solved tasks in the accumulated regression set, using their saved\nbaselines and the declared tolerances. Reject or repair regressions rather\nthan hiding them in an average. Confirm noisy wins with the planned evidence,\nincluding all planned attempts and costs. Bank the verified candidate and\nupdate the parameter-effect map with interactions and task-specific limits.
\nExpand only after progress. Once the active task meets its local criterion\nand prior tasks remain green, add one task or a small batch that probes a new\nfailure mode or an uncertain effect in the map. Establish missing baselines\nonly for those tasks. If a new task fails, make it the active task, return to\nhypothesis planning, and retain the old tasks as regression checks. Do not\nrepeatedly run the expanded suite while debugging that one failure.
\nThis curriculum changes discovery coverage, not the overall success criteria.\nReserve broader evaluation for coverage-expansion checkpoints and final\nconfirmation. A single-task win cannot complete a broader objective.
\nReplan from what was learned. After a hypothesis batch, a new failure, or\nseveral non-improving trials, consolidate the map and choose the next most\ninformative batch. Change the suspected mechanism or experiment design when\nthe evidence contradicts it; do not endlessly retune one family or rerun the\nsame tests. Revisit a rejected idea only with a changed premise. Continue\nwithout asking whether to proceed after each experiment.
\nUse the project's existing format; keep these views compact and linked to evidence:
\nContinue within the authorized session and limits until the target passes its\nrequired validation, the user stops the work, a budget is exhausted, or a genuine\nexternal blocker prevents useful progress. A plateau calls for replanning, not\nan invented claim of optimality. Preserve research state across continuations;\nthis skill does not itself schedule future work.
\nAt a stopping boundary, leave the incumbent recoverable and account for pending\njobs. Deliver the parameter-effect map, baseline versus best verified results,\ncoverage and limitations, budget consumed, stop reason, and exact next experiment\nif unfinished. Meeting a score does not replace recording what the experiments\nestablished; an unfinished run still leaves a useful map of what is known.
\n","files":[{"path":"SKILL.md","sizeBytes":10825,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-10-14T21:49:33.76839Z","sha256":"637C1F9028CFADC15ABD334AF14BE0E575F243F51B1254F2682CE44F80B83492","sizeBytes":4720},"review":null,"source":{"repositoryUrl":"https://github.com/dzhng/skills","path":"skills/engineering/auto-research","license":"MIT","commit":"f2fbf92f131fb08bbf3e400a1ef99b7be85bb2bc","subtreeSha":"D9F6950EBDB3FA4A862270F0F0510A8632D1C2B6A2738CF19501450C65CE2B6B","lastSyncedAt":"2026-10-14T21:49:23.275319Z"},"reviewedAt":"2026-10-14T21:50:00.954601Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/dzhng/skills/tree/main/skills/engineering/auto-research"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install dzhng-skills@llmmart"},{"target":"git","command":"git clone https://github.com/dzhng/skills.git"}]}