autonomous-research-loop

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Autonomous Research Loop

## Overview

Run autonomous engineering and experiment loops with strict acceptance gates.
Treat partial completion as unfinished work and continue until completion criteria are met.

## Operating Contract

Apply these rules for every run:

1. Initialize git context at start.
2. Keep repository synchronized if remote exists.
3. Continue execution until objective is completed or a hard blocker is proven.
4. Validate behavior with runnable checks, not only static edits.
5. Commit every meaningful fix.
6. Push when remote is configured and credentials allow push.
7. Treat tests as hard completion gates, not optional checks.
8. In YOLO mode (`--dangerously-bypass-approvals-and-sandbox`), assume full execution power and apply extra caution before any destructive command.
9. Maintain project-local execution memory under `argusbot/` for session continuity.

## Step 0: Bootstrap Git Safely

Execute at task start:

```bash
git init
```

Then detect repo and remote status:

```bash
git rev-parse --is-inside-work-tree
git remote -v
```

If a remote and tracked branch exist, try to sync before edits:

```bash
git pull --rebase --autostash
```

If pull fails, continue local work and record reason in status updates.

## Step 0.5: Create Local Execution Memory

At project root, create and maintain an `argusbot/` directory.

Required files:

1. `argusbot/current-session.md`
2. `argusbot/todo.md`
3. `argusbot/todo_session.md`

Update them at start and after every meaningful loop iteration.

`argusbot/current-session.md` must contain:

1. Current objective
2. What was completed in this session
3. Latest commands run
4. Latest validation result
5. Latest commit hash
6. Current blockers or risks

`argusbot/todo.md` must contain:

1. Remaining work items
2. Next highest-priority action
3. Any deferred investigation

`argusbot/todo_session.md` must contain:

1. Session-specific objective interpretation
2. Completed items in this session
3. Remaining items for this session
4. Latest operator injects that materially changed scope
5. What should be checked first in the next session

Purpose:

1. Preserve rough working memory across long sessions
2. Make resume/re-entry easier even if model context changes
3. Leave a human-readable trail inside the project itself

Inject handling rule:

1. If an inject changes core scope, replaces a requirement, adds a major subtask, or changes completion criteria, treat it as a primary-task inject and update `argusbot/todo_session.md` immediately.
2. If an inject is only a reminder, small preference, or tactical nudge that does not materially change scope, record it in `argusbot/current-session.md` but do not rewrite `argusbot/todo_session.md`.
3. When uncertain, prefer treating the inject as primary-task relevant and update `argusbot/todo_session.md`.

## Step 1: Define Completion Gates Up Front

Before coding, derive explicit objective gates:

1. Code/functionality gate: requested behavior is implemented.
2. Validation gate: tests or runnable checks pass.
3. Runtime gate for training/experiments: smoke run reaches at least 100 steps.
4. Artifact gate: at least one usable checkpoint is produced and readable.
5. Inference gate: perform a minimal inference/load check from produced checkpoint.

Do not stop at planning text. Execute commands to satisfy gates.

Mandatory interpretation:

1. Module/system design work is incomplete until relevant tests pass.
2. Training work is incomplete until checkpoint generation and inference/load verification pass.
3. If tests are missing, add focused tests that cover the delivered behavior.

## Step 2: Execute in Persistent Loop

Use an iterative loop until gates are all green:

1. Inspect code and logs.
2. Implement next concrete fix.
3. Run targeted checks.
4. Re-evaluate all gates.
5. Continue immediately if any gate is red.

From waltstephen/ArgusBot, MIT.

More from waltstephen/ArgusBot