Agent skill

Autonomous Loops

by affaan-m in affaan-m/ECC

Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems.

MITAuto-check passedAgent Workflows

Install Autonomous Loops

skills CLI
$ npx skills add affaan-m/ECC --skill autonomous-loops -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install affaan-m/ECC autonomous-loops --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/affaan-m/ECC.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/autonomous-loops .claude/skills/autonomous-loops && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
autonomous-loops
GitHub stars
277k
Used in
4 other repos
Token cost
~5.8k tokens
SKILL.md length
1,665 words
Files
1
Skills in repo
683
Repo updated
First seen
Licence
MIT

At a glance

Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems.

  • Works in 6 steps: Sequential Pipeline (claude -p) → NanoClaw REPL → Infinite Agentic Loop → …
  • Tasks that involve Autonomous loops
  • SKILL.md covers When to Use, Loop Pattern Spectrum, 1. Sequential Pipeline (claude… and 2. NanoClaw REPL, plus 3 more sections
  • Calls claude, node and gh

What it does

Autonomous Loops is an agent skill from affaan-m/ECC. Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems. Retained for compatibility only: when new autonomous loop guidance is needed, use continuous-agent-loop instead.

Its SKILL.md is about 5.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows, covering Autonomous loops. The repository describes itself as: The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond. The licence is MIT.

When your agent uses it

  • Tasks that involve Autonomous loops

Example prompts

  • “Use the autonomous-loops skill to pattern and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven…”
  • “/autonomous-loops”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Sequential Pipeline (claude -p)
  2. NanoClaw REPL
  3. Infinite Agentic Loop
  4. Continuous Claude PR Loop
  5. The De-Sloppify Pattern
  6. Ralphinho / RFC-Driven DAG Orchestration

What it can do on your machine

Read from SKILL.md and the folder at commit 2d515e4. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • claude
    • node
    • gh
    • npm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Autonomous Loops loads about 5.8k tokens when it runs. Until then it costs about 66 tokens; SKILL.md has 1,665 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~66
When it runs · the whole SKILL.md, loaded when a task matches
~5.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from affaan-m/ECC at commit 2d515e4, republished under its MIT licence (© affaan-m). 1,665 words, ~5,809 tokens.

Download SKILL.mdSave it as .claude/skills/autonomous-loops/SKILL.md (or your agent's skills folder).
name
autonomous-loops
description
Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems. Retained for compatibility only: when new autonomous loop guidance is needed, use continuous-agent-loop instead.
metadata.origin
ECC

Autonomous Loops Skill

Compatibility note (v1.8.0): autonomous-loops is retained for one release. The canonical skill name is now continuous-agent-loop. New loop guidance should be authored there, while this skill remains available to avoid breaking existing workflows.

Patterns, architectures, and reference implementations for running Claude Code autonomously in loops. Covers everything from simple claude -p pipelines to full RFC-driven multi-agent DAG orchestration.

When to Use

  • Setting up autonomous development workflows that run without human intervention
  • Choosing the right loop architecture for your problem (simple vs complex)
  • Building CI/CD-style continuous development pipelines
  • Running parallel agents with merge coordination
  • Implementing context persistence across loop iterations
  • Adding quality gates and cleanup passes to autonomous workflows

Loop Pattern Spectrum

From simplest to most sophisticated:

PatternComplexityBest For
Sequential PipelineLowDaily dev steps, scripted workflows
NanoClaw REPLLowInteractive persistent sessions
Infinite Agentic LoopMediumParallel content generation, spec-driven work
Continuous Claude PR LoopMediumMulti-day iterative projects with CI gates
De-Sloppify PatternAdd-onQuality cleanup after any Implementer step
Ralphinho / RFC-Driven DAGHighLarge features, multi-unit parallel work with merge queue

1. Sequential Pipeline (claude -p)

The simplest loop. Break daily development into a sequence of non-interactive claude -p calls. Each call is a focused step with a clear prompt.

Core Insight

If you can't figure out a loop like this, it means you can't even drive the LLM to fix your code in interactive mode.

The claude -p flag runs Claude Code non-interactively with a prompt, exits when done. Chain calls to build a pipeline:

bash
#!/bin/bash
# daily-dev.sh — Sequential pipeline for a feature branch

set -e

# Step 1: Implement the feature
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."

# Step 2: De-sloppify (cleanup pass)
claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."

# Step 3: Verify
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."

# Step 4: Commit
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."
Key Design Principles
  1. Each step is isolated — A fresh context window per claude -p call means no context bleed between steps.
  2. Order matters — Steps execute sequentially. Each builds on the filesystem state left by the previous.
  3. Negative instructions are dangerous — Don't say "don't test type systems." Instead, add a separate cleanup step (see De-Sloppify Pattern).
  4. Exit codes propagate — set -e stops the pipeline on failure.
Variations

With model routing:

bash
# Research with Opus (deep reasoning)
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."

# Implement with Sonnet (fast, capable)
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."

# Review with Opus (thorough)
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."

With environment context:

bash
# Pass context via files, not prompt length
echo "Focus areas: auth module, API rate limiting" > .claude-context.md
claude -p "Read .claude-context.md for priorities. Work through them in order."
rm .claude-context.md

With --allowedTools restrictions:

bash
# Read-only analysis pass
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."

# Write-only implementation pass
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."

2. NanoClaw REPL

ECC's built-in persistent loop. A session-aware REPL that calls claude -p synchronously with full conversation history.

bash
# Start the default session
node scripts/claw.js

# Named session with skill context
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
How It Works
  1. Loads conversation history from ~/.claude/claw/{session}.md
  2. Each user message is sent to claude -p with full history as context
  3. Responses are appended to the session file (Markdown-as-database)
  4. Sessions persist across restarts
When NanoClaw vs Sequential Pipeline
Use CaseNanoClawSequential Pipeline
Interactive explorationYesNo
Scripted automationNoYes
Session persistenceBuilt-inManual
Context accumulationGrows per turnFresh each step
CI/CD integrationPoorExcellent

See the /claw command documentation for full details.


3. Infinite Agentic Loop

A two-prompt system that orchestrates parallel sub-agents for specification-driven generation. Developed by disler (credit: @disler).

Architecture: Two-Prompt System
PROMPT 1 (Orchestrator)              PROMPT 2 (Sub-Agents)
┌─────────────────────┐             ┌──────────────────────┐
│ Parse spec file      │             │ Receive full context  │
│ Scan output dir      │  deploys   │ Read assigned number  │
│ Plan iteration       │────────────│ Follow spec exactly   │
│ Assign creative dirs │  N agents  │ Generate unique output │
│ Manage waves         │             │ Save to output dir    │
└─────────────────────┘             └──────────────────────┘
The Pattern
  1. Spec Analysis — Orchestrator reads a specification file (Markdown) defining what to generate
  2. Directory Recon — Scans existing output to find the highest iteration number
  3. Parallel Deployment — Launches N sub-agents, each with:
    • The full spec
    • A unique creative direction
    • A specific iteration number (no conflicts)
    • A snapshot of existing iterations (for uniqueness)
  4. Wave Management — For infinite mode, deploys waves of 3-5 agents until context is exhausted
Implementation via Claude Code Commands

Create .claude/commands/infinite.md:

markdown
Parse the following arguments from $ARGUMENTS:
1. spec_file — path to the specification markdown
2. output_dir — where iterations are saved
3. count — integer 1-N or "infinite"

PHASE 1: Read and deeply understand the specification.
PHASE 2: List output_dir, find highest iteration number. Start at N+1.
PHASE 3: Plan creative directions — each agent gets a DIFFERENT theme/approach.
PHASE 4: Deploy sub-agents in parallel (Task tool). Each receives:
  - Full spec text
  - Current directory snapshot
  - Their assigned iteration number
  - Their unique creative direction
PHASE 5 (infinite mode): Loop in waves of 3-5 until context is low.

Invoke:

bash
/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite
Batching Strategy
CountStrategy
1-5All agents simultaneously
6-20Batches of 5
infiniteWaves of 3-5, progressive sophistication
Key Insight: Uniqueness via Assignment

Don't rely on agents to self-differentiate. The orchestrator assigns each agent a specific creative direction and iteration number. This prevents duplicate concepts across parallel agents.


4. Continuous Claude PR Loop

A production-grade shell script that runs Claude Code in a continuous loop, creating PRs, waiting for CI, and merging automatically. Created by AnandChowdhary (credit: @AnandChowdhary).

Core Loop
┌─────────────────────────────────────────────────────┐
│  CONTINUOUS CLAUDE ITERATION                        │
│                                                     │
│  1. Create branch (continuous-claude/iteration-N)   │
│  2. Run claude -p with enhanced prompt              │
│  3. (Optional) Reviewer pass — separate claude -p   │
│  4. Commit changes (claude generates message)       │
│  5. Push + create PR (gh pr create)                 │
│  6. Wait for CI checks (poll gh pr checks)          │
│  7. CI failure? → Auto-fix pass (claude -p)         │
│  8. Merge PR (squash/merge/rebase)                  │
│  9. Return to main → repeat                         │
│                                                     │
│  Limit by: --max-runs N | --max-cost $X             │
│            --max-duration 2h | completion signal     │
└─────────────────────────────────────────────────────┘
Installation

Warning: Install continuous-claude from its repository after reviewing the code. Do not pipe external scripts directly to bash.

Usage
bash
# Basic: 10 iterations
continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10

# Cost-limited
continuous-claude --prompt "Fix all linter errors" --max-cost 5.00

# Time-boxed
continuous-claude --prompt "Improve test coverage" --max-duration 8h

# With code review pass
continuous-claude \
  --prompt "Add authentication feature" \
  --max-runs 10 \
  --review-prompt "Run npm test && npm run lint, fix any failures"

# Parallel via worktrees
continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
wait
Cross-Iteration Context: SHARED_TASK_NOTES.md

The critical innovation: a SHARED_TASK_NOTES.md file persists across iterations:

markdown
## Progress
- [x] Added tests for auth module (iteration 1)
- [x] Fixed edge case in token refresh (iteration 2)
- [ ] Still need: rate limiting tests, error boundary tests

## Next Steps
- Focus on rate limiting module next
- The mock setup in tests/helpers.ts can be reused

Claude reads this file at iteration start and updates it at iteration end. This bridges the context gap between independent claude -p invocations.

CI Failure Recovery

When PR checks fail, Continuous Claude automatically:

  1. Fetches the failed run ID via gh run list
  2. Spawns a new claude -p with CI fix context
  3. Claude inspects logs via gh run view, fixes code, commits, pushes
  4. Re-waits for checks (up to --ci-retry-max attempts)
Completion Signal

Claude can signal "I'm done" by outputting a magic phrase:

bash
continuous-claude \
  --prompt "Fix all bugs in the issue tracker" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # Stops after 3 consecutive signals

Three consecutive iterations signaling completion stops the loop, preventing wasted runs on finished work.

Key Configuration
FlagPurpose
--max-runs NStop after N successful iterations
--max-cost $XStop after spending $X
--max-duration 2hStop after time elapsed
--merge-strategy squashsquash, merge, or rebase
--worktree <name>Parallel execution via git worktrees
--disable-commitsDry-run mode (no git operations)
--review-prompt "..."Add reviewer pass per iteration
--ci-retry-max NAuto-fix CI failures (default: 1)

5. The De-Sloppify Pattern

An add-on pattern for any loop. Add a dedicated cleanup/refactor step after each Implementer step.

The Problem

When you ask an LLM to implement with TDD, it takes "write tests" too literally:

  • Tests that verify TypeScript's type system works (testing typeof x === 'string')
  • Overly defensive runtime checks for things the type system already guarantees
  • Tests for framework behavior rather than business logic
  • Excessive error handling that obscures the actual code
Why Not Negative Instructions?

Adding "don't test type systems" or "don't add unnecessary checks" to the Implementer prompt has downstream effects:

  • The model becomes hesitant about ALL testing
  • It skips legitimate edge case tests
  • Quality degrades unpredictably
The Solution: Separate Pass

Instead of constraining the Implementer, let it be thorough. Then add a focused cleanup agent:

bash
# Step 1: Implement (let it be thorough)
claude -p "Implement the feature with full TDD. Be thorough with tests."

# Step 2: De-sloppify (separate context, focused cleanup)
claude -p "Review all changes in the working tree. Remove:
- Tests that verify language/framework behavior rather than business logic
- Redundant type checks that the type system already enforces
- Over-defensive error handling for impossible states
- Console.log statements
- Commented-out code

Keep all business logic tests. Run the test suite after cleanup to ensure nothing breaks."
In a Loop Context
bash
for feature in "${features[@]}"; do
  # Implement
  claude -p "Implement $feature with TDD."

  # De-sloppify
  claude -p "Cleanup pass: review changes, remove test/code slop, run tests."

  # Verify
  claude -p "Run build + lint + tests. Fix any failures."

  # Commit
  claude -p "Commit with message: feat: add $feature"
done
Key Insight

Rather than adding negative instructions which have downstream quality effects, add a separate de-sloppify pass. Two focused agents outperform one constrained agent.


6. Ralphinho / RFC-Driven DAG Orchestration

The most sophisticated pattern. An RFC-driven, multi-agent pipeline that decomposes a spec into a dependency DAG, runs each unit through a tiered quality pipeline, and lands them via an agent-driven merge queue. Created by enitrat (credit: @enitrat).

Architecture Overview
RFC/PRD Document
       │
       ▼
  DECOMPOSITION (AI)
  Break RFC into work units with dependency DAG
       │
       ▼
┌──────────────────────────────────────────────────────┐
│  RALPH LOOP (up to 3 passes)                         │
│                                                      │
│  For each DAG layer (sequential, by dependency):     │
│                                                      │
│  ┌── Quality Pipelines (parallel per unit) ───────┐  │
│  │  Each unit in its own worktree:                │  │
│  │  Research → Plan → Implement → Test → Review   │  │
│  │  (depth varies by complexity tier)             │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── Merge Queue ─────────────────────────────────┐  │
│  │  Rebase onto main → Run tests → Land or evict │  │
│  │  Evicted units re-enter with conflict context  │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
└──────────────────────────────────────────────────────┘
Show full SKILL.md (697 more words)Show less
RFC Decomposition

AI reads the RFC and produces work units:

typescript
interface WorkUnit {
  id: string;              // kebab-case identifier
  name: string;            // Human-readable name
  rfcSections: string[];   // Which RFC sections this addresses
  description: string;     // Detailed description
  deps: string[];          // Dependencies (other unit IDs)
  acceptance: string[];    // Concrete acceptance criteria
  tier: "trivial" | "small" | "medium" | "large";
}

Decomposition Rules:

  • Prefer fewer, cohesive units (minimize merge risk)
  • Minimize cross-unit file overlap (avoid conflicts)
  • Keep tests WITH implementation (never separate "implement X" + "test X")
  • Dependencies only where real code dependency exists

The dependency DAG determines execution order:

Layer 0: [unit-a, unit-b]     ← no deps, run in parallel
Layer 1: [unit-c]             ← depends on unit-a
Layer 2: [unit-d, unit-e]     ← depend on unit-c
Complexity Tiers

Different tiers get different pipeline depths:

TierPipeline Stages
trivialimplement → test
smallimplement → test → code-review
mediumresearch → plan → implement → test → PRD-review + code-review → review-fix
largeresearch → plan → implement → test → PRD-review + code-review → review-fix → final-review

This prevents expensive operations on simple changes while ensuring architectural changes get thorough scrutiny.

Separate Context Windows (Author-Bias Elimination)

Each stage runs in its own agent process with its own context window:

StageModelPurpose
ResearchSonnetRead codebase + RFC, produce context doc
PlanOpusDesign implementation steps
ImplementCodexWrite code following the plan
TestSonnetRun build + test suite
PRD ReviewSonnetSpec compliance check
Code ReviewOpusQuality + security check
Review FixCodexAddress review issues
Final ReviewOpusQuality gate (large tier only)

Critical design: The reviewer never wrote the code it reviews. This eliminates author bias — the most common source of missed issues in self-review.

Merge Queue with Eviction

After quality pipelines complete, units enter the merge queue:

Unit branch
    │
    ├─ Rebase onto main
    │   └─ Conflict? → EVICT (capture conflict context)
    │
    ├─ Run build + tests
    │   └─ Fail? → EVICT (capture test output)
    │
    └─ Pass → Fast-forward main, push, delete branch

File Overlap Intelligence:

  • Non-overlapping units land speculatively in parallel
  • Overlapping units land one-by-one, rebasing each time

Eviction Recovery: When evicted, full context is captured (conflicting files, diffs, test output) and fed back to the implementer on the next Ralph pass:

markdown
## MERGE CONFLICT — RESOLVE BEFORE NEXT LANDING

Your previous implementation conflicted with another unit that landed first.
Restructure your changes to avoid the conflicting files/lines below.

{full eviction context with diffs}
Data Flow Between Stages
research.contextFilePath ──────────────────→ plan
plan.implementationSteps ──────────────────→ implement
implement.{filesCreated, whatWasDone} ─────→ test, reviews
test.failingSummary ───────────────────────→ reviews, implement (next pass)
reviews.{feedback, issues} ────────────────→ review-fix → implement (next pass)
final-review.reasoning ────────────────────→ implement (next pass)
evictionContext ───────────────────────────→ implement (after merge conflict)
Worktree Isolation

Every unit runs in an isolated worktree (uses jj/Jujutsu, not git):

/tmp/workflow-wt-{unit-id}/

Pipeline stages for the same unit share a worktree, preserving state (context files, plan files, code changes) across research → plan → implement → test → review.

Key Design Principles
  1. Deterministic execution — Upfront decomposition locks in parallelism and ordering
  2. Human review at leverage points — The work plan is the single highest-leverage intervention point
  3. Separate concerns — Each stage in a separate context window with a separate agent
  4. Conflict recovery with context — Full eviction context enables intelligent re-runs, not blind retries
  5. Tier-driven depth — Trivial changes skip research/review; large changes get maximum scrutiny
  6. Resumable workflows — Full state persisted to SQLite; resume from any point
When to Use Ralphinho vs Simpler Patterns
SignalUse RalphinhoUse Simpler Pattern
Multiple interdependent work unitsYesNo
Need parallel implementationYesNo
Merge conflicts likelyYesNo (sequential is fine)
Single-file changeNoYes (sequential pipeline)
Multi-day projectYesMaybe (continuous-claude)
Spec/RFC already writtenYesMaybe
Quick iteration on one thingNoYes (NanoClaw or pipeline)

Choosing the Right Pattern

Decision Matrix
Is the task a single focused change?
├─ Yes → Sequential Pipeline or NanoClaw
└─ No → Is there a written spec/RFC?
         ├─ Yes → Do you need parallel implementation?
         │        ├─ Yes → Ralphinho (DAG orchestration)
         │        └─ No → Continuous Claude (iterative PR loop)
         └─ No → Do you need many variations of the same thing?
                  ├─ Yes → Infinite Agentic Loop (spec-driven generation)
                  └─ No → Sequential Pipeline with de-sloppify
Combining Patterns

These patterns compose well:

  1. Sequential Pipeline + De-Sloppify — The most common combination. Every implement step gets a cleanup pass.

  2. Continuous Claude + De-Sloppify — Add --review-prompt with a de-sloppify directive to each iteration.

  3. Any loop + Verification — Use ECC's /verify command or verification-loop skill as a gate before commits.

  4. Ralphinho's tiered approach in simpler loops — Even in a sequential pipeline, you can route simple tasks to Haiku and complex tasks to Opus:

    bash
    # Simple formatting fix
    claude -p --model haiku "Fix the import ordering in src/utils.ts"
    
    # Complex architectural change
    claude -p --model opus "Refactor the auth module to use the strategy pattern"

Anti-Patterns

Common Mistakes
  1. Infinite loops without exit conditions — Always have a max-runs, max-cost, max-duration, or completion signal.

  2. No context bridge between iterations — Each claude -p call starts fresh. Use SHARED_TASK_NOTES.md or filesystem state to bridge context.

  3. Retrying the same failure — If an iteration fails, don't just retry. Capture the error context and feed it to the next attempt.

  4. Negative instructions instead of cleanup passes — Don't say "don't do X." Add a separate pass that removes X.

  5. All agents in one context window — For complex workflows, separate concerns into different agent processes. The reviewer should never be the author.

  6. Ignoring file overlap in parallel work — If two parallel agents might edit the same file, you need a merge strategy (sequential landing, rebase, or conflict resolution).


References

ProjectAuthorLink
Ralphinhoenitratcredit: @enitrat
Infinite Agentic Loopdislercredit: @disler
Continuous ClaudeAnandChowdharycredit: @AnandChowdhary
NanoClawECC/claw command in this repo
Verification LoopECCskills/verification-loop/ in this repo

© affaan-m, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/autonomous-loops of affaan-m/ECC.

Open the folder on GitHubat commit 2d515e4

Used in 4 other repositories

We found 10 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 4 other GitHub owners. This page covers the copy in affaan-m/ECC, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Autonomous Loops next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Autonomous Loops compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Autonomous Loops this skillaffaan-m/ECC277k4 repos~5.8kAutomated safety check: PassMIT
Show Me Your Work Decision Logcursor/plugins11k8 repos~1.6kAutomated safety check: PassNone
Autoresearch Iteration Loopuditgoenka/autoresearch6.5k1 repos~2kAutomated safety check: PassMIT
Install Loop Engineeringcobusgreyling/loop-engineering11k1 repos~648Automated safety check: PassMIT
LoopyForward-Future/loopy3.2k—~3.9kAutomated safety check: PassMIT
AI Performance Improvement Plantanweai/pua20k2 repos~6.9kAutomated safety check: PassMIT

Similar skills

  • Official

    Keeps a TSV decision log for long or unattended agent runs, one row per decision with what, why, evidence and result, so a reviewer can check the work later.

    11k GitHub starsUsed in 8 repos~1.6k tokens
    Agent WorkflowsAuto-check passed
  • Autoresearch Iteration Loop

    uditgoenka/autoresearch

    Runs an autonomous modify, verify, keep-or-discard loop against any metric, with subcommands for planning, debugging, fixing, security audits, shipping and more.

    6.5k GitHub starsUsed in 1 repo~2k tokens
    Agent WorkflowsAuto-check passed
  • Install Loop Engineering

    cobusgreyling/loop-engineering

    Installs Loop Engineering into a project through the single @cobusgreyling/loop CLI, scaffolding a report-only loop and a readiness score.

    11k GitHub starsUsed in 1 repo~648 tokens
    Agent WorkflowsAuto-check passed
  • Loopy

    Forward-Future/loopy

    Discover, find, compare, audit, repair, adapt, craft, run, debrief, save, and prepare repeatable AI-agent loops for publication.

    3.2k GitHub stars~3.9k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • Pushes an agent to exhaust every option, investigate before asking and take initiative beyond the literal request, instead of giving up or waiting passively.

    20k GitHub starsUsed in 2 repos~6.9k tokens
    Agent WorkflowsAuto-check passed
  • LoopX Self Repair

    loopx-project/loopx

    Diagnoses surprising LoopX behavior, such as stale recommendations or tiny progress, assigns it to the responsible layer and repairs it at the lowest durable level.

    6.2k GitHub stars~2.2k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from affaan-m/ECC

All 682 skills in this repo
  • Skill Stocktake

    affaan-m/ECC

    Audits your installed Claude skills and commands for quality, with a quick mode for recently changed skills and a full mode that evaluates all of them through subagents.

    277k GitHub starsUsed in 5 repos~3.1k tokens
    Auto-check passed
  • Ingests, indexes, searches, edits and monitors video, audio and live streams through the VideoDB Python SDK, returning stream links, clips and timestamps.

    277k GitHub starsUsed in 3 repos~3.5k tokens
    Auto-check: notes
  • Docs Governance

    affaan-m/ECC

    Route broad documentation-governance requests to existing ECC skills and run an opt-in, read-only audit of mapped documentation roles, links, ADR indexes, and evidence references.

    277k GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Rules Distillation

    affaan-m/ECC

    Scans installed skills for principles that recur across them and proposes rule-file changes: append, revise, add a section, create a file or leave as covered.

    277k GitHub starsUsed in 2 repos~2.3k tokens
    Auto-check passed
  • Builds DRAFT counterparty agreements from one markdown template and a small JSON spec per party, with clauses picked by the party's role.

    277k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Set an ECC-specific frontend design direction for production UI work.

    277k GitHub starsUsed in 1 repo~2.2k tokens
    Auto-check passed

Categories

Questions about Autonomous Loops

What does Autonomous Loops do?

Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems. Autonomous Loops is an agent skill from affaan-m/ECC. Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems.

When should I use Autonomous Loops?

Autonomous Loops fits situations like: tasks that involve Autonomous loops.

How do I install Autonomous Loops in Claude Code?

Run `npx skills add affaan-m/ECC --skill autonomous-loops -a claude-code`. Or copy the skill folder (skills/autonomous-loops in affaan-m/ECC) into .claude/skills/autonomous-loops in your project. Claude Code loads it when a task matches its description.

How do I install Autonomous Loops in Codex?

Run `npx skills add affaan-m/ECC --skill autonomous-loops -a codex`. Or copy the skill folder (skills/autonomous-loops in affaan-m/ECC) into .agents/skills/autonomous-loops in your project. Codex loads it when a task matches its description.

Can I use Autonomous Loops in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add affaan-m/ECC --skill autonomous-loops -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/autonomous-loops, .gemini/skills/autonomous-loops, .github/skills/autonomous-loops and .opencode/skills/autonomous-loops in your project.

What does Autonomous Loops need to run?

Going by SKILL.md and its folder, Autonomous Loops needs the command-line tools its instructions call (claude, node, gh and npm).

Does Autonomous Loops access the network?

SKILL.md contains no URLs. Its commands use gh and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Autonomous Loops safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Autonomous Loops use?

Autonomous Loops is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Autonomous Loops use?

About 5.8k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Autonomous Loops?

Skills that share tags, products or a category with Autonomous Loops: Show Me Your Work Decision Log (cursor/plugins, 11k stars), Autoresearch Iteration Loop (uditgoenka/autoresearch, 6.5k stars), Install Loop Engineering (cobusgreyling/loop-engineering, 11k stars) and Loopy (Forward-Future/loopy, 3.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Autonomous Loops?

affaan-m (a GitHub user) maintains it in affaan-m/ECC, which has 276,673 GitHub stars. The repository holds 683 skills in this directory. The repository was last updated on October 11, 2026.

Source: affaan-m/ECC on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.