resume

Overview of resume skill

What the resume skill is for

The resume skill is a Claude workflow skill for continuing a paused autoresearch experiment instead of restarting from a vague memory of prior work. It is triggered by /ar:resume or by a user asking to pick up a previously started experiment. Its real job is to restore the experiment branch, read the saved configuration, strategy, results history, and recent commits, then summarize the current state before continuing iteration.

Best-fit users and repositories

This resume skill fits teams using the autoresearch-agent structure from alirezarezvani/claude-skills, especially repositories where experiments are stored under .autoresearch/{domain}/{name}/ and branches follow autoresearch/{domain}/{name}. It is most useful for engineering optimization work, benchmark-driven changes, and long-running experiment loops where the agent needs to know what was already tried, kept, discarded, or crashed.

What makes it different from a normal resume prompt

A generic “continue where we left off” prompt depends on chat memory. This skill gives the agent a concrete recovery path: list experiments if no name is provided, checkout the correct branch, read config.cfg, program.md, results.tsv, and inspect recent git history. That structure reduces duplicate work and helps the agent continue from evidence rather than assumptions.

Key adoption consideration

The skill is compact and installation-light, but it assumes the surrounding autoresearch workflow exists. Before adopting it for Workflow Automation, confirm your repository uses compatible experiment branches, stores result history in .autoresearch/, and has the helper script referenced by the skill available in the expected installed context.

How to Use resume skill

resume install and first files to inspect

Install the skill from the source repository with:

npx skills add alirezarezvani/claude-skills --skill resume

After install, read SKILL.md first. This skill has no extra local README.md, references, rules, or bundled scripts in its skill folder, so the important implementation detail is the command sequence documented in SKILL.md. Also inspect the wider engineering/autoresearch-agent area of the repository if your installer pulls the full skill collection, because /ar:resume references scripts/setup_experiment.py.

Calling the resume skill in practice

Use the command without an argument when you want the agent to list available experiments:

/ar:resume

Use a specific experiment path when you already know the domain and name:

/ar:resume engineering/api-speed

A strong prompt gives the skill permission to inspect the repository and states what kind of continuation you want:

“Run /ar:resume engineering/api-speed. After loading the branch and .autoresearch files, summarize the best result, failed attempts, current hypothesis, and propose the next safe experiment before editing code.”

This is better than “resume the speed experiment” because it tells the agent to recover state first and prevents it from jumping directly into code changes.

Expected workflow after invocation

The skill’s intended workflow is:

1. If no experiment name is provided, list available experiments and let the user choose.
2. Checkout autoresearch/{domain}/{name}.
3. Read .autoresearch/{domain}/{name}/config.cfg for target, metric, and constraints.
4. Read program.md for the experiment strategy.
5. Read results.tsv for prior trials and outcomes.
6. Review recent branch commits with git log --oneline -20.
7. Report the current state before continuing.

For best results, ask for a state report before approving another experiment. The report should include total experiments, kept/discarded/crashed counts, best metric, baseline, last attempted change, and recent patterns.

Practical prompt patterns for better output

Use the resume skill when the decision depends on historical experiment evidence. Good follow-up requests include:

• “Do not repeat discarded approaches unless the reason for failure has changed.”
• “Compare the next proposed change against the best kept result in results.tsv.”
• “Before editing, identify any crashed experiments that indicate unsafe directions.”
• “If the branch is dirty, stop and explain the working tree state first.”

These instructions improve output quality because the agent must connect new work to saved results, not merely generate a plausible next optimization.

resume skill FAQ

Is resume only for autoresearch experiments?

Yes, in practice. The resume skill is written around the autoresearch convention: experiment branches named autoresearch/{domain}/{name} and state files under .autoresearch/{domain}/{name}/. You can adapt the idea to other workflows, but out of the box it is not a general project resume tool.

What does the resume skill need before it works?

It needs an initialized experiment with a branch, configuration file, strategy file, and results table. If config.cfg, program.md, or results.tsv are missing, the agent may still inspect git history, but the core value of the skill is reduced because it cannot reconstruct prior decisions reliably.

How is this useful for Workflow Automation?

For Workflow Automation, the skill creates a repeatable recovery routine. Instead of every automation run asking the model to infer context, /ar:resume standardizes what gets loaded and reported. That is valuable for scheduled benchmark loops, interrupted optimization tasks, or multi-session agent work where reproducibility matters.

When should I not use this skill?

Do not use it for a fresh experiment, a one-off code edit, or a repository without autoresearch state. It is also a poor fit if your experiment data lives only in chat transcripts, issue comments, or external dashboards. In those cases, write a custom recovery prompt or add a companion skill that knows where your actual history is stored.

How to Improve resume skill

Give resume stronger experiment inputs

The resume skill performs best when the saved experiment files are clean and decision-oriented. Keep config.cfg explicit about the target file, metric, direction, baseline, and constraints. Keep program.md focused on strategy, not chatty notes. Keep results.tsv consistent, with enough detail to distinguish kept changes, discarded changes, crashes, and measurement noise.

Prevent common resume failure modes

The most common failure is continuing without fully loading context. Ask the agent to confirm the branch name, config, strategy, result count, best result, and last commit before it proposes changes. Another failure is over-trusting the latest result; require comparison against the best historical result and ask whether the improvement is meaningful for the metric.

Iterate after the first resumed output

After the skill reports state, improve the next step with targeted questions:

• “Which previous attempts should be avoided and why?”
• “What is the smallest reversible experiment from here?”
• “What evidence suggests this direction is better than the discarded ones?”
• “What command should validate success before marking KEEP?”

This turns the resume guide into an evidence-based loop rather than a simple branch checkout.

Customize the skill for your repository

If your team uses different branch names, result formats, or experiment directories, edit the skill instructions to match those conventions. Useful additions include a dirty-working-tree check, a required test or benchmark command, a results schema description, and a rule to stop before destructive git operations. These changes make the resume skill safer and more reliable without changing its core purpose: recover experiment context and continue from the strongest available evidence.