deli-autoresearch

Name: deli-autoresearch
Author: vukrosic

15stars0forks

How to install deli-autoresearch?

vukrosic/deli-autoresearch/deli-autoresearch

$npx -y skills add vukrosic/deli-autoresearch --skill deli-autoresearch

Installs into the current project.

Summary

A protocol framework for long-horizon autonomous tasks. Targets three empirically-observed failure modes — cognitive loops, stalling, runtime fragility — by prescribing state management, stall detection, and watchdog mechanisms. Validated on multiple task types including paper wr

Files · 1

View on GitHub

SKILL.md

1	# Deli_AutoResearch
2
3	This skill is a protocol framework for long-horizon autonomous tasks (days to weeks). It ships no executable code; instead it prescribes a set of battle-tested conventions: how state is persisted, how stalls are detected, how guardians are layered, and what constraints bind agent behavior. Implementation details are left to the adopter's environment.
4
5	## 1. Motivation
6
7	Long-running code agents exhibit three recurring failure modes:
8
9	1. Cognitive loop — successive iterations try similar directions with diminishing returns, unable to escape a local optimum on their own.
10	2. Stalling — the agent finishes a chunk of work, outputs a summary, and waits for user feedback. Externally the session looks alive and polling runs, but work has effectively stopped. Run logs show this is more common than crashes.
11	3. Runtime fragility — context compaction silently breaks the loop; closing a session takes down the timers parasitic on it. Failures go unnoticed by default.
12
13	The common cause of all three is missing engineering scaffolding, not insufficient model capability. Every mechanism in this framework targets the failure modes above.
14
15	## 2. Behavioral Constraints
16
17	1. Zero interaction — no prompting the user during a run: no Plan Mode, no question tool, no ending on a question. Continue working until the user stops you. Resolve ambiguity yourself and write the reasoning to the log (level=decision).
18	2. Ready means execute — the most common hidden violation: finishing all preparation and then asking "should I submit?". The purpose of preparation is execution; submitting, resubmitting, fixing, and starting monitors are all routine operations needing no confirmation.
19	3. Callback means report-alive — after context compaction the loop dies silently. The first action of every callback is to update its own last_seen, then check liveness; on detecting failure it restarts immediately and logs it.
20	4. Persist state to files — all progress is written to state/ files, not conversation memory. Each iteration starts a fresh session, injecting only curated state; never use resume.
21	5. Guardian / worker separation — a heartbeat patrol may take only three actions on tasks that are not its own: liveness-check, restart, nudge. It does not read their data, modify their state files, or report to the user on their behalf.
22
23	## 3. Architecture
24
25	┌── Orchestrator (current session / durable cron) ──┐
26	│ monitor state files → detect stalls → inject direction │
27	└────┬─────────────┬─────────────┬────────────┘
28	[Task A] [Task B] [Task C] ← each its own fresh session
29
30	Core design decisions:
31	- Separate execution from evaluation — the agent doing the work does not judge its own progress; stall determination is made by the orchestration layer based on quantitative metrics.
32	- Fresh session over resume — context accumulation is the primary cause of cognitive loops. Each iteration starts with fresh context; state is injected via files.
33	- Enforced direction diversity — before each iteration, read the list of tried directions; a new direction must differ from all history.
34
35	## 4. State Files
36
37	{task}/state/
38	├── task_spec.md # goal / milestones / success criteria
39	├── progress.json # {iteration, total_findings, status, stale_count}
40	├── findings.jsonl # accumulated findings (append-only)
41	├── directions_tried.json # directions already tried
42	└── iteration_log.jsonl # per-iteration summary
43
44	{task}/logs/
45	├── work.jsonl # written by work agent; decisions tagged level=decision
46	├── orchestrator.jsonl # written by orchestrator
47	└── heartbeat.jsonl # written by heartbeat watchdog
48
49	Log line format: {"ts":"...", "source":"...", "level":"info\|warn\|error\|decision", "event":"...", "detail":"..."}
50
51	## 5. Usage
52
53	# 1. Initialize the task directory, write state/task_spec.md and an initial progress.json
54
55	# 2. Start the orchestrator loop:
56	/loop 2h check all tasks under : (1) read progress.json;
57	(2) if stale_count>=3 generate a fresh direction; (3) launch a work agent
58	via the Agent tool (with explicit goal and completion criteria);
59	(4) write results back to state files. Zero interaction.
60
61	# 3. Register a durable heartbeat watchdog (survives across sessions):
62	hourly patrol: write a timestamp; check each loop's last_seen against interval×3,
63	restart if exceeded; check each task's progress

People who liked this also viewed

6 picks

Type

deli-autoresearch

15stars0forks

View on GitHub

How to install deli-autoresearch?

vukrosic/deli-autoresearch/deli-autoresearch

$npx -y skills add vukrosic/deli-autoresearch --skill deli-autoresearch

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Deli_AutoResearch
2
3	This skill is a protocol framework for long-horizon autonomous tasks (days to weeks). It ships no executable code; instead it prescribes a set of battle-tested conventions: how state is persisted, how stalls are detected, how guardians are layered, and what constraints bind agent behavior. Implementation details are left to the adopter's environment.
4
5	## 1. Motivation
6
7	Long-running code agents exhibit three recurring failure modes:
8
9	1. Cognitive loop — successive iterations try similar directions with diminishing returns, unable to escape a local optimum on their own.
10	2. Stalling — the agent finishes a chunk of work, outputs a summary, and waits for user feedback. Externally the session looks alive and polling runs, but work has effectively stopped. Run logs show this is more common than crashes.
11	3. Runtime fragility — context compaction silently breaks the loop; closing a session takes down the timers parasitic on it. Failures go unnoticed by default.
12
13	The common cause of all three is missing engineering scaffolding, not insufficient model capability. Every mechanism in this framework targets the failure modes above.
14
15	## 2. Behavioral Constraints
16
17	1. Zero interaction — no prompting the user during a run: no Plan Mode, no question tool, no ending on a question. Continue working until the user stops you. Resolve ambiguity yourself and write the reasoning to the log (level=decision).
18	2. Ready means execute — the most common hidden violation: finishing all preparation and then asking "should I submit?". The purpose of preparation is execution; submitting, resubmitting, fixing, and starting monitors are all routine operations needing no confirmation.
19	3. Callback means report-alive — after context compaction the loop dies silently. The first action of every callback is to update its own last_seen, then check liveness; on detecting failure it restarts immediately and logs it.
20	4. Persist state to files — all progress is written to state/ files, not conversation memory. Each iteration starts a fresh session, injecting only curated state; never use resume.
21	5. Guardian / worker separation — a heartbeat patrol may take only three actions on tasks that are not its own: liveness-check, restart, nudge. It does not read their data, modify their state files, or report to the user on their behalf.
22
23	## 3. Architecture
24
25	┌── Orchestrator (current session / durable cron) ──┐
26	│ monitor state files → detect stalls → inject direction │
27	└────┬─────────────┬─────────────┬────────────┘
28	[Task A] [Task B] [Task C] ← each its own fresh session
29
30	Core design decisions:
31	- Separate execution from evaluation — the agent doing the work does not judge its own progress; stall determination is made by the orchestration layer based on quantitative metrics.
32	- Fresh session over resume — context accumulation is the primary cause of cognitive loops. Each iteration starts with fresh context; state is injected via files.
33	- Enforced direction diversity — before each iteration, read the list of tried directions; a new direction must differ from all history.
34
35	## 4. State Files
36
37	{task}/state/
38	├── task_spec.md # goal / milestones / success criteria
39	├── progress.json # {iteration, total_findings, status, stale_count}
40	├── findings.jsonl # accumulated findings (append-only)
41	├── directions_tried.json # directions already tried
42	└── iteration_log.jsonl # per-iteration summary
43
44	{task}/logs/
45	├── work.jsonl # written by work agent; decisions tagged level=decision
46	├── orchestrator.jsonl # written by orchestrator
47	└── heartbeat.jsonl # written by heartbeat watchdog
48
49	Log line format: {"ts":"...", "source":"...", "level":"info\|warn\|error\|decision", "event":"...", "detail":"..."}
50
51	## 5. Usage
52
53	# 1. Initialize the task directory, write state/task_spec.md and an initial progress.json
54
55	# 2. Start the orchestrator loop:
56	/loop 2h check all tasks under : (1) read progress.json;
57	(2) if stale_count>=3 generate a fresh direction; (3) launch a work agent
58	via the Agent tool (with explicit goal and completion criteria);
59	(4) write results back to state files. Zero interaction.
60
61	# 3. Register a durable heartbeat watchdog (survives across sessions):
62	hourly patrol: write a timestamp; check each loop's last_seen against interval×3,
63	restart if exceeded; check each task's progress

People who liked this also viewed

6 picks

Type