メニュー
Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | autonomous-loops |
| description | Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems. |
| origin | ECC |
互換性に関する注意（v1.8.0）:
autonomous-loopsは1リリース分保持されます。 正規のスキル名はcontinuous-agent-loopになりました。新しいループガイダンスは そちらで作成してください。既存のワークフローを壊さないよう、このスキルは引き続き 利用可能です。
Claude Code を自律的にループで実行するためのパターン、アーキテクチャ、リファレンス実装です。シンプルな claude -p パイプラインから、RFC 駆動のマルチエージェント DAG オーケストレーションまでをカバーします。
最もシンプルなものから最も高度なものまで:
| パターン | 複雑度 | 最適な用途 |
|---|---|---|
| Sequential Pipeline | 低 | 日次開発ステップ、スクリプト化されたワークフロー |
| NanoClaw REPL | 低 | インタラクティブな永続セッション |
| Infinite Agentic Loop | 中 | 並列コンテンツ生成、仕様駆動の作業 |
| Continuous Claude PR Loop | 中 | CI ゲート付きの複数日にわたる反復プロジェクト |
| De-Sloppify Pattern | アドオン | Implementer ステップ後の品質クリーンアップ |
| Ralphinho / RFC-Driven DAG | 高 | 大規模機能、マージキュー付きのマルチユニット並列作業 |
claude -p)最もシンプルなループです。 日常の開発をノンインタラクティブな claude -p コールのシーケンスに分解します。各コールは明確なプロンプトを持つ集中したステップです。
このようなループを構築できないなら、インタラクティブモードでも LLM にコードを修正させることすらできないということです。
claude -p フラグはプロンプト付きでノンインタラクティブに Claude Code を実行し、完了時に終了します。コールをチェインしてパイプラインを構築します:
#!/bin/bash
# daily-dev.sh — フィーチャーブランチ用の Sequential Pipeline
set -e
# Step 1: 機能の実装
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（クリーンアップパス）
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: 検証
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."
# Step 4: コミット
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."
claude -p コールごとに新しいコンテキストウィンドウが開始されるため、ステップ間でコンテキストの漏洩がありません。set -e により、失敗時にパイプラインが停止します。モデルルーティング付き:
# Opus で調査（深い推論）
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."
# Sonnet で実装（高速、高性能）
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."
# Opus でレビュー（徹底的）
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."
環境コンテキスト付き:
# プロンプトの長さではなく、ファイル経由でコンテキストを渡す
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
--allowedTools 制限付き:
# 読み取り専用の分析パス
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."
# 書き込み専用の実装パス
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."
ECC 組み込みの永続ループです。 完全な会話履歴付きで claude -p を同期的に呼び出すセッション対応 REPL です。
# デフォルトセッションを開始
node scripts/claw.js
# スキルコンテキスト付きの名前付きセッション
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
~/.claude/claw/{session}.md から会話履歴を読み込みますclaude -p に送信されます| ユースケース | NanoClaw | Sequential Pipeline |
|---|---|---|
| インタラクティブな探索 | はい | いいえ |
| スクリプト化された自動化 | いいえ | はい |
| セッション永続化 | 組み込み | 手動 |
| コンテキスト蓄積 | ターンごとに増加 | 各ステップで新規 |
| CI/CD 統合 | 不向き | 最適 |
詳細は /claw コマンドのドキュメントを参照してください。
2つのプロンプトからなるシステム で、仕様駆動の生成のために並列サブエージェントを調整します。disler が開発（credit: @disler）。
PROMPT 1 (Orchestrator) PROMPT 2 (Sub-Agents)
┌─────────────────────┐ ┌──────────────────────┐
│ 仕様ファイルをパース │ │ フルコンテキストを受信 │
│ 出力ディレクトリをスキャン │ deploys │ 割り当て番号を読み取り │
│ イテレーションを計画 │────────────│ 仕様に正確に従う │
│ クリエイティブな方向を割当│ N agents │ ユニークな出力を生成 │
│ ウェーブを管理 │ │ 出力ディレクトリに保存 │
└─────────────────────┘ └──────────────────────┘
.claude/commands/infinite.md を作成:
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.
呼び出し:
/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite
| カウント | 戦略 |
|---|---|
| 1-5 | 全エージェントを同時実行 |
| 6-20 | 5個ずつのバッチ |
| infinite | 3-5のウェーブ、段階的に洗練度を向上 |
エージェント自身に差別化を任せないでください。オーケストレーターが各エージェントに特定のクリエイティブの方向性とイテレーション番号を 割り当て ます。これにより、並列エージェント間でコンセプトの重複が防止されます。
本番品質のシェルスクリプト で、Claude Code を継続ループで実行し、PR を作成し、CI を待ち、自動的にマージします。AnandChowdhary が作成（credit: @AnandChowdhary）。
┌─────────────────────────────────────────────────────┐
│ CONTINUOUS CLAUDE ITERATION │
│ │
│ 1. ブランチを作成 (continuous-claude/iteration-N) │
│ 2. 拡張プロンプト付きで claude -p を実行 │
│ 3. (オプション) レビューパス — 別の claude -p │
│ 4. 変更をコミット（claude がメッセージを生成） │
│ 5. プッシュ＋PR 作成 (gh pr create) │
│ 6. CI チェックを待機（gh pr checks をポーリング） │
│ 7. CI 失敗？→ 自動修正パス (claude -p) │
│ 8. PR をマージ (squash/merge/rebase) │
│ 9. main に戻る → 繰り返し │
│ │
│ 制限: --max-runs N | --max-cost $X │
│ --max-duration 2h | completion signal │
└─────────────────────────────────────────────────────┘
警告: コードを確認した上で、リポジトリから continuous-claude をインストールしてください。外部スクリプトを直接 bash にパイプしないでください。
# 基本: 10イテレーション
continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10
# コスト制限付き
continuous-claude --prompt "Fix all linter errors" --max-cost 5.00
# 時間制限付き
continuous-claude --prompt "Improve test coverage" --max-duration 8h
# コードレビューパス付き
continuous-claude \
--prompt "Add authentication feature" \
--max-runs 10 \
--review-prompt "Run npm test && npm run lint, fix any failures"
# worktree 経由の並列実行
continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
wait
重要なイノベーション: SHARED_TASK_NOTES.md ファイルがイテレーション間で永続化されます:
## 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 はイテレーション開始時にこのファイルを読み取り、イテレーション終了時に更新します。これにより、独立した claude -p 呼び出し間のコンテキストギャップが橋渡しされます。
PR チェックが失敗した場合、Continuous Claude は自動的に以下を行います:
gh run list 経由で失敗したラン ID を取得claude -p を起動gh run view 経由でログを確認し、コードを修正、コミット、プッシュ--ci-retry-max 回の試行）Claude は「完了」をマジックフレーズの出力でシグナルできます:
continuous-claude \
--prompt "Fix all bugs in the issue tracker" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 3 # 3回連続のシグナル後に停止
3回連続で完了シグナルを送信するとループが停止し、完了した作業に対する無駄な実行を防ぎます。
| フラグ | 目的 |
|---|---|
--max-runs N | N 回の成功イテレーション後に停止 |
--max-cost $X | $X の支出後に停止 |
--max-duration 2h | 経過時間後に停止 |
--merge-strategy squash | squash、merge、または rebase |
--worktree <name> | git worktree 経由の並列実行 |
--disable-commits | ドライランモード（git 操作なし） |
--review-prompt "..." | イテレーションごとにレビューパスを追加 |
--ci-retry-max N | CI 失敗の自動修正（デフォルト: 1） |
任意のループのアドオンパターンです。 Implementer ステップの後に専用のクリーンアップ/リファクタリングステップを追加します。
LLM に TDD で実装を依頼すると、「テストを書く」を文字通りに解釈しすぎます:
typeof x === 'string' のテスト）Implementer プロンプトに「型システムをテストしないで」や「不要なチェックを追加しないで」を追加すると、下流に影響が出ます:
Implementer を制約する代わりに、徹底的に作業させます。その後、集中したクリーンアップエージェントを追加します:
# Step 1: 実装（徹底的に）
claude -p "Implement the feature with full TDD. Be thorough with tests."
# Step 2: De-sloppify（別のコンテキスト、集中したクリーンアップ）
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."
for feature in "${features[@]}"; do
# 実装
claude -p "Implement $feature with TDD."
# De-sloppify
claude -p "Cleanup pass: review changes, remove test/code slop, run tests."
# 検証
claude -p "Run build + lint + tests. Fix any failures."
# コミット
claude -p "Commit with message: feat: add $feature"
done
下流の品質に影響を与える否定的な指示を追加する代わりに、別の de-sloppify パスを追加してください。集中した2つのエージェントは、制約された1つのエージェントよりも優れています。
最も高度なパターンです。 RFC 駆動のマルチエージェントパイプラインで、仕様を依存関係 DAG に分解し、各ユニットを階層的な品質パイプラインを通して実行し、エージェント駆動のマージキューを介してランディングします。enitrat が作成（credit: @enitrat）。
RFC/PRD Document
│
▼
DECOMPOSITION (AI)
RFC をワークユニットと依存関係 DAG に分解
│
▼
┌──────────────────────────────────────────────────────┐
│ RALPH LOOP (最大3パス) │
│ │
│ 各 DAG レイヤーについて（依存関係順に逐次）: │
│ │
│ ┌── Quality Pipelines（ユニットごとに並列）────────┐ │
│ │ 各ユニットは独自の worktree 内: │ │
│ │ Research → Plan → Implement → Test → Review │ │
│ │ （深度は複雑度ティアにより変動） │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌── Merge Queue ─────────────────────────────────┐ │
│ │ main にリベース → テスト実行 → ランドまたは追放│ │
│ │ 追放されたユニットはコンフリクトコンテキスト付きで│ │
│ │ 再投入 │ │
│ └────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
AI が RFC を読み取り、ワークユニットを生成します:
interface WorkUnit {
id: string; // kebab-case の識別子
name: string; // 人間が読める名前
rfcSections: string[]; // この作業が対応する RFC セクション
description: string; // 詳細な説明
deps: string[]; // 依存関係（他のユニット ID）
acceptance: string[]; // 具体的な受け入れ基準
tier: "trivial" | "small" | "medium" | "large";
}
分解ルール:
依存関係 DAG が実行順序を決定します:
Layer 0: [unit-a, unit-b] ← 依存関係なし、並列実行
Layer 1: [unit-c] ← unit-a に依存
Layer 2: [unit-d, unit-e] ← unit-c に依存
異なるティアに異なるパイプライン深度が適用されます:
| ティア | パイプラインステージ |
|---|---|
| trivial | implement → test |
| small | implement → test → code-review |
| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
| large | research → plan → implement → test → PRD-review + code-review → review-fix → final-review |
これにより、シンプルな変更に対する高コストな操作を防ぎつつ、アーキテクチャの変更には徹底的な精査が行われます。
各ステージは独自のエージェントプロセスと独自のコンテキストウィンドウで実行されます:
| ステージ | モデル | 目的 |
|---|---|---|
| Research | Sonnet | コードベース＋RFC を読み取り、コンテキストドキュメントを生成 |
| Plan | Opus | 実装ステップを設計 |
| Implement | Codex | プランに従ってコードを書く |
| Test | Sonnet | ビルド＋テストスイートを実行 |
| PRD Review | Sonnet | 仕様準拠チェック |
| Code Review | Opus | 品質＋セキュリティチェック |
| Review Fix | Codex | レビュー指摘への対応 |
| Final Review | Opus | 品質ゲート（large ティアのみ） |
重要な設計: レビューアーがレビューするコードを書いたことはありません。これにより著者バイアスが排除されます。これはセルフレビューで見逃される問題の最も一般的な原因です。
品質パイプライン完了後、ユニットはマージキューに入ります:
Unit branch
│
├─ main にリベース
│ └─ コンフリクト？→ 追放（コンフリクトコンテキストをキャプチャ）
│
├─ ビルド＋テスト実行
│ └─ 失敗？→ 追放（テスト出力をキャプチャ）
│
└─ パス → main を fast-forward、プッシュ、ブランチ削除
ファイル重複のインテリジェンス:
追放からの回復: 追放時、完全なコンテキスト（コンフリクトファイル、diff、テスト出力）がキャプチャされ、次の Ralph パスで実装者にフィードバックされます:
## MERGE CONFLICT — RESOLVE BEFORE NEXT LANDING
あなたの前の実装は、先にランディングした別のユニットとコンフリクトしました。
以下のコンフリクトしているファイル/行を回避するよう、変更を再構築してください。
{full eviction context with diffs}
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 で実行されます（git ではなく jj/Jujutsu を使用）:
/tmp/workflow-wt-{unit-id}/
同じユニットのパイプラインステージは worktree を 共有 し、research → plan → implement → test → review にわたって状態（コンテキストファイル、プランファイル、コード変更）を保持します。
| シグナル | Ralphinho を使用 | シンプルなパターンを使用 |
|---|---|---|
| 複数の相互依存するワークユニット | はい | いいえ |
| 並列実装が必要 | はい | いいえ |
| マージコンフリクトの可能性 | はい | いいえ（逐次で十分） |
| 単一ファイルの変更 | いいえ | はい（sequential pipeline） |
| 複数日のプロジェクト | はい | 場合による（continuous-claude） |
| 仕様/RFC が既に書かれている | はい | 場合による |
| 1つのことに対する素早いイテレーション | いいえ | はい（NanoClaw またはパイプライン） |
タスクは単一の集中した変更か？
├─ はい → Sequential Pipeline または NanoClaw
└─ いいえ → 書かれた仕様/RFC があるか？
├─ はい → 並列実装が必要か？
│ ├─ はい → Ralphinho（DAG オーケストレーション）
│ └─ いいえ → Continuous Claude（反復 PR ループ）
└─ いいえ → 同じもののバリエーションが多数必要か？
├─ はい → Infinite Agentic Loop（仕様駆動の生成）
└─ いいえ → Sequential Pipeline + de-sloppify
これらのパターンはうまく組み合わせられます:
Sequential Pipeline + De-Sloppify — 最も一般的な組み合わせです。すべての実装ステップにクリーンアップパスが付きます。
Continuous Claude + De-Sloppify — 各イテレーションに de-sloppify ディレクティブ付きの --review-prompt を追加します。
任意のループ + Verification — コミット前のゲートとして ECC の /verify コマンドまたは verification-loop スキルを使用します。
Ralphinho のティアアプローチをシンプルなループで — sequential pipeline でも、シンプルなタスクを Haiku に、複雑なタスクを Opus にルーティングできます:
# シンプルなフォーマット修正
claude -p --model haiku "Fix the import ordering in src/utils.ts"
# 複雑なアーキテクチャ変更
claude -p --model opus "Refactor the auth module to use the strategy pattern"
終了条件のない無限ループ — 常に max-runs、max-cost、max-duration、または completion signal を設定してください。
イテレーション間のコンテキスト橋渡しなし — 各 claude -p コールは新規で始まります。SHARED_TASK_NOTES.md やファイルシステムの状態を使ってコンテキストを橋渡ししてください。
同じ失敗のリトライ — イテレーションが失敗した場合、単にリトライしないでください。エラーコンテキストをキャプチャして次の試行にフィードしてください。
クリーンアップパスの代わりに否定的な指示 — 「X をしないで」と言わないでください。X を除去する別のパスを追加してください。
すべてのエージェントを1つのコンテキストウィンドウに — 複雑なワークフローでは、関心を異なるエージェントプロセスに分離してください。レビューアーは著者であってはなりません。
並列作業でのファイル重複の無視 — 2つの並列エージェントが同じファイルを編集する可能性がある場合、マージ戦略（逐次ランディング、リベース、またはコンフリクト解決）が必要です。
| プロジェクト | 作者 | リンク |
|---|---|---|
| Ralphinho | enitrat | credit: @enitrat |
| Infinite Agentic Loop | disler | credit: @disler |
| Continuous Claude | AnandChowdhary | credit: @AnandChowdhary |
| NanoClaw | ECC | このリポジトリの /claw コマンド |
| Verification Loop | ECC | このリポジトリの skills/verification-loop/ |
キャプチャ、診断、抑制されたリカバリ、内省レポートを用いた、AI エージェント障害向けの体系的なセルフデバッグワークフローです。
リポジトリ認識の並列レビューパスを使用してスキル、コマンド、ルール、フック、その他を DAILY と LIBRARY のバケットに分類することで、特定のリポジトリ向けにエビデンスに基づく ECC インストールプランを構築します。フルバンドルをロードするのではなく、プロジェクトが実際に必要とするものに ECC をトリミングすべき場合に使用します。
対象リポジトリの既存の統合パターンに正確に合わせて新しい API コネクタやプロバイダを構築します。第二のアーキテクチャを発明することなく、もう一つの統合を追加する場合に使用します。
Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
ECC 向けのエビデンスファーストな自動化インベントリと重複監査のワークフローです。何かを修正する前に、どのジョブ、フック、コネクタ、MCP サーバー、またはラッパーがライブ、壊れている、冗長、または欠落しているかをユーザーが知りたい場合に使用します。
CodeTour の `.tour` ファイルを作成します。実際のファイルと行のアンカーを持つペルソナ対象のステップバイステップウォークスルーです。オンボーディングツアー、アーキテクチャウォークスルー、PR ツアー、RCA ツアー、および構造化された「これがどのように動作するか説明して」というリクエストに使用します。