autonomous-loop

name	autonomous-loop
description	Use when given a multi-step research / coding / data-processing task that requires more than one round of implement → verify → fix, and you want closure without per-step human confirmation. Triggering signals — task says "run + analyze + report", "finish all of X", "iterate until done"; or you would otherwise pause to ask "is this what you wanted?" between every step.
argument-hint	["task description"]
allowed-tools	Read, Grep, Glob, Bash, Edit, Write, Agent, TodoWrite
effort	high

Autonomous Closed-Loop Iteration

After receiving a task from the user, complete the entire iteration loop autonomously. Do not wait for human confirmation at each step.

Execution Flow

① Understand → ② Verify State → ③ Plan → ④ Implement
       ↓                                       ↓
⑧ Deliver  ←  ⑦ Update Docs  ←  ⑥ Fix  ←  ⑤ Self-Validate
                                   ↑            │
                                   └── failed ──┘

Step 1: Understand the Task

• Clarify what the user wants (goal + boundaries)
• Identify what is explicitly out of scope
• Break down into subtasks with TodoWrite

Step 2: Verify Current State (Critical — Never Skip)

Before writing any code or making any claims:

• Read source code to confirm data formats, interfaces, and APIs — never guess
• Check actual files on disk (configs, checkpoints, outputs) — never rely on memory or compressed summaries alone
• Check resources (GPU availability, disk space, running processes)
• Review relevant history in project memory and discussion logs for past lessons

Step 3: Plan the Approach

• Follow existing code patterns — prefer "do it the way the codebase already does it" over inventing new approaches
• Align with project conventions (directory structure, naming, config format)
• Identify risks and define how to verify success

Step 4: Implement

• Write files to the designated workspace directory only
• After each code change, list all modified files and line numbers
• Never use destructive operations (rm, rm -rf) — move unwanted files to trash/
• Persist all non-trivial commands for reproducibility:
  • Python → save to claude_workspace/scripts/<snake_case>.py (no long inline python -c)
  • Shell pipelines → save to claude_workspace/shell/<snake_case>.sh (#!/bin/bash, set -e)
  • Append a concise entry to claude_workspace/shell/RUN_LOG.md: Goal / Cmd / Issue / Fix / Out
  • Exempt: read-only one-liners (ls, git status, grep, find, rtk meta)

Step 5: Self-Validate (Key Differentiator)

Do not wait for human verification. Run these checks yourself:

#	Check	Method
1	Dimension consistency	Print shapes, compare against source code expectations
2	Value sanity	Check for NaN/Inf, compare value ranges with baseline
3	File completeness	Confirm output file count, sizes are reasonable
4	Metric reasonableness	Compare with prior experiment results; investigate large deviations
5	Config consistency	Verify paths, parameters point to correct targets
6	Naming and location	Confirm compliance with project directory and naming conventions

Step 6: Fix

• If self-validation finds issues, diagnose the root cause and fix it yourself
• After fixing, return to Step 5 and re-validate
• Log the problem and fix (to be written into discussion records later)

Step 7: Update Documentation

• Append to the project discussion log if new issues or findings emerged
• Update experiment overview or other tracking documents if results changed
• Sync memory backups if memory was updated

Step 8: Deliver

• Save reports to the correct location following project naming conventions
• Mark tasks complete in TodoWrite
• Provide a concise summary to the user: conclusions + key numbers + file locations

Common Mistakes (and the fix for each)

Distilled from past human-AI failures in this project. Same table covers "what to do / what not to do" plus the symptom you'll see when you slip.

Principle	Do this	NOT this	Symptom when you slip
No guessing	Read dataloader / source code to confirm formats	Infer data layout from variable names	Wrong dimensions, key error, all-zeros
No stale state	ls / cat actual files before writing reports	Trust compressed context summaries	Report contradicts what's on disk
Follow existing patterns	Analyze how the codebase already solves it	Invent a new approach from scratch	Over-engineered solution, drift from project conventions
Handle edge cases	Check for zeros, NaN, missing files	Assume data is clean	Silent NaN propagation, divisions by zero
Verify paths	ls actual directories before relying on configs	Assume paths from config are flat	FileNotFoundError mid-run
No destructive ops	mv to trash/	rm or rm -rf	Lost work, irreversible mistakes
Document as you go	Update Discussion / report after each significant step	Batch all docs to the end	Missing context when reviewing later
Sync persistent state	Sync memory backups immediately after updates	Forget; do it "later"	Backup out of date when needed
Persist commands	Save python to scripts/, shell to shell/, log Goal/Cmd/Issue/Fix/Out	Long ad-hoc python -c / one-shot bash	Cannot reproduce, lessons lost
Check resource contention	nvidia-smi, ps aux --sort=-%cpu before debugging perf	Assume GPU is free	Pipeline 100× slower with no error

Red Flags — STOP and Loop Back

If you catch yourself doing any of these, you've drifted from the loop. Pause, fix, re-validate.

• "I'll just trust the README / context summary, no need to verify" → Step 2 was skipped
• "Let me write this report based on my memory of the experiment" → Step 5 was skipped
• "It's just one quick rm to clean up" → No-destructive rule violated
• "I'll run python -c '...' real quick, no need to save it" → Persist commands rule violated
• "Skipping smoke test, the change is small" → Self-validate (Step 5) was skipped
• "It's slow but probably normal, let me wait" without checking nvidia-smi → resource-contention check skipped
• "I'll update Discussion.md at the end" but the task has 5+ findings → Document-as-you-go skipped
• "Memory was edited; I'll sync at the end" → Sync-persistent-state skipped
• Three consecutive Bash commands without reading any source code → "No guessing" violated

When to Still Ask the Human

Even in autonomous mode, pause and ask for human input when:

1. Direction decisions — choosing between fundamentally different experiment designs
2. Destructive or irreversible actions — pushing code, modifying files outside workspace
3. Heavy resource allocation — starting long-running training jobs on shared GPUs
4. Ambiguous trade-offs — when multiple valid approaches exist with unclear preference
5. Novel problem types — no prior lesson or convention exists to guide the decision

Usage Examples

/autonomous-loop Run test on the latest checkpoint, postprocess results, and generate a report
/autonomous-loop Analyze per-joint error comparison between v4 and v6
/autonomous-loop Clean up expired caches and intermediate checkpoints
/autonomous-loop Prepare dataset for a new experiment variant