deli-autoresearch

Deli AutoResearch

Overview

Deli AutoResearch is a set of conventions for running a long, unattended agent task. Instead of leaving the loop to manage itself, you keep its state in files, make each round try something genuinely different, decide whether it's stuck by counting results, and run a separate heartbeat watchdog that restarts the loop if it dies.

Core principle: don't trust a long-running agent to remember, grade itself, or stay alive. Keep state outside the chat, keep the worker and the thing that judges it separate, and restart from files you control.

When to Use

Use this for:

• Multi-hour or multi-day research, literature, writing, benchmark, or exploration tasks
• Autonomous runs where the user explicitly authorized zero-interaction operation
• Tasks prone to repeating the same approach, waiting for feedback, or dying silently
• Multi-agent exploration where each worker needs a distinct direction
• Experiment loops that require submit, monitor, diagnose, fix, and resubmit cycles

Do not use this for:

• Small one-shot code edits or simple debugging
• Work that requires frequent human judgment before acting
• External actions not explicitly authorized by the user
• Tasks without any verifiable progress metric or validation step

Behavioral Contract

When operating under this skill, follow these constraints for the scoped run:

1. Zero interaction after launch — do not ask questions, enter plan mode, or stop on "should I continue?" Resolve ambiguity and log the decision with level=decision.
2. Ready means execute — if preparation is complete, proceed with routine actions: submit, monitor, fix, resubmit, verify, and restart monitors.
3. Persist state to files — progress, findings, directions, and logs live in {task}/state/ and {task}/logs/, not in chat memory.
4. Fresh session over resume — start each worker iteration from curated state files. Avoid accumulated context and resume unless the user specifically requires it.
5. Separate guardian and worker duties — watchdogs may liveness-check, restart, and nudge only. They must not edit worker findings or impersonate worker summaries.
6. External side effects need scope — pushing, posting, emailing, spending, deleting, or modifying third-party resources requires prior explicit authorization.

Minimal Startup Checklist

1. Confirm unattended scope is authorized.
2. Create {task}/state/ and {task}/logs/ (full layout in references/state-schema.md).
3. Write task_spec.md with goal, allowed actions, validation, and stop conditions.
4. Initialize progress.json, findings.jsonl, directions_tried.json, and iteration_log.jsonl.
5. Start the orchestrator loop (see templates/orchestrator.md).
6. Start a separate heartbeat watchdog (see templates/heartbeat.md).
7. Validate after every iteration (methods in references/patterns.md).
8. Escalate instead of silently abandoning blocked work.

Read-When-Needed Map

Load subfiles only when the situation calls for them — do not preload everything.

Templates — read when about to launch a role:

• templates/orchestrator.md — orchestrator per-callback checklist and prompt
• templates/worker.md — worker requirements and prompt
• templates/heartbeat.md — watchdog allowed/forbidden actions and prompt

References — read when the situation applies:

• references/state-schema.md — directory layout, file formats, log record shape
• references/stall-and-pivot.md — stall thresholds, structural vs tactical pivots, direction-diversity dimensions
• references/patterns.md — subagent scheduling patterns, validation methods, escalation report format, common mistakes

Role → files to load:

Role	Load
Orchestrator	orchestrator.md + stall-and-pivot.md
Worker	worker.md + state-schema.md
Heartbeat	heartbeat.md
Validation or escalation moment	patterns.md