自律ループスキル

互換性に関する注記 (v1.8.0): autonomous-loops は1つのリリースサイクルが保持されます。 規範的なスキル名は現在 continuous-agent-loop です。新しいループガイドはここに記述する必要があり、このスキルは既存のワークフローを破壊しないよう引き続き利用可能です。

ループ内で Claude Code を自律的に実行するパターン、アーキテクチャ、参照実装。シンプルな claude -p パイプラインから、完全な RFC 駆動の複数エージェント DAG オーケストレーションまでのあらゆるものをカバーしています。

使用する場合

• 人間による介入なしに実行可能な自律開発ワークフローを確立する
• 問題に適切なループアーキテクチャを選択する（シンプル vs 複雑）
• CI/CD スタイルの継続的開発パイプラインを構築する
• マージコーディネーションを備えた並列エージェントを実行する
• ループイテレーション間でコンテキストの永続化を実装する
• 自律ワークフローに品質ゲートとクリーンアップステップを追加する

ループパターンスペクトラム

最もシンプルから最も複雑まで：

パターン	複雑度	最適用途
シーケンシャルパイプライン	低	日常的な開発ステップ、スクリプト化されたワークフロー
NanoClaw REPL	低	インタラクティブな永続セッション
無限エージェントループ	中	並列コンテンツ生成、仕様駆動作業
継続的 Claude PR ループ	中	CI ゲートを備えた複数日プロジェクトの反復
スロッピネス除去パターン	追加	任意の実装者ステップ後の品質クリーンアップ
Ralphinho / RFC 駆動の DAG	高	大規模フィーチャー、マージキューを備えた複数ユニット並列作業

---

1. シーケンシャルパイプライン (claude -p)

最もシンプルなループ。 日常的な開発を一連の非インタラクティブ claude -p 呼び出しに分解します。各呼び出しは明確なプロンプトを持つ焦点を絞ったステップです。

コアインサイト

そのようなループを考え出せないなら、それはインタラクティブモードで LLM を使ってコードを修正することさえできないことを意味しています。

claude -p フラグはプロンプト付きで Claude Code を非インタラクティブに実行し、完了時に終了します。呼び出しをチェーンしてパイプラインを構築します：

#!/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."

重要な設計原則

1. 各ステップは独立している — 各 claude -p 呼び出しは新しいコンテキストウィンドウであり、ステップ間でコンテキストリークはありません。
2. 順序が重要 — ステップは順序で実行されます。各ステップは前のステップが残したファイルシステムの状態に基づきます。
3. 否定指令は危険 — 「型システムをテストしないでください」と言わないでください。代わりに、別の清理ステップを追加してください（スロッピネス除去パターンを参照）。
4. 終了コードが伝播される — set -e は失敗時にパイプラインを停止します。

バリアント

モデルルーティングを使用する：

# 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..."

環境コンテキストを使用する：

# 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

--allowedTools 制限を使用する：

# 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 組み込みの永続ループ。 完全な会話履歴を同期 claude -p 呼び出しで使用するセッション認識 REPL。

# 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

動作方法

1. ~/.claude/claw/{session}.md から会話履歴を読み込む
2. 各ユーザーメッセージが完全な履歴と共にコンテキストとして claude -p に送信される
3. レスポンスはセッションファイルに追加される（Markdown as database）
4. セッションは再起動後も永続化される

NanoClaw vs シーケンシャルパイプライン

ユースケース	NanoClaw	シーケンシャルパイプライン
インタラクティブな探索	はい	いいえ
スクリプト化された自動化	いいえ	はい
セッション永続性	組み込み	手動
コンテキスト蓄積	各ラウンドで増加	各ステップは新規
CI/CD 統合	悪い	優秀

詳細については、/claw コマンドドキュメントを参照してください。

---

3. 無限エージェントループ

仕様駆動生成用の並列サブエージェントをオーケストレーションする二重プロンプトシステム。 disler により開発（謝辞：@disler）。

アーキテクチャ：二重プロンプトシステム

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    │
└─────────────────────┘             └──────────────────────┘

パターン

1. 仕様分析 — オーケストレータが生成対象のコンテンツを定義する仕様ファイル（Markdown）を読み込む
2. ディレクトリ偵察 — 既存の出力をスキャンして最高のイテレーション番号を検出
3. 並列デプロイ — N個のサブエージェントを起動、各々に以下を提供：
   • 完全な仕様
   • ユニークな創造的方向
   • 特定のイテレーション番号（競合なし）
   • 既存イテレーションのスナップショット（ユニーク性を確保するため）
4. ウェーブ管理 — 無限モードでは、コンテキスト尽果まで 3-5 個エージェントのウェーブをデプロイ

Claude Code コマンドで実装

.claude/commands/infinite.md を作成：

$ARGUMENTS から以下のパラメータを解析：
1. spec_file — 仕様 Markdown ファイルのパス
2. output_dir — イテレーション結果を保存するディレクトリ
3. count — 整数 1-N または "infinite"

フェーズ 1：仕様を読み込み深く理解する。
フェーズ 2：output_dir をリストし、最高のイテレーション番号を検出。N+1 から開始。
フェーズ 3：創造的方向を計画 — 各エージェントは**異なる**トピック/アプローチを取得。
フェーズ 4：サブエージェントを並列デプロイ（Task ツールを使用）。各エージェントは以下を受け取る：
  - 完全な仕様テキスト
  - 現在のディレクトリスナップショット
  - 割り当てられたイテレーション番号
  - 割り当てられたユニークな創造的方向
フェーズ 5（無限モード）：コンテキスト不足になるまで 3-5 個を 1 ウェーブとして循環。

呼び出し：

/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite

バッチ処理戦略

数量	戦略
1-5	すべてのエージェント同時実行
6-20	各バッチ 5 個
無限	3-5 個を 1 ウェーブ、段階的に複雑化

重要なインサイト：割り当てによるユニーク性の実現

エージェント自身の差別化に依存しないでください。オーケストレータが各エージェントに特定の創造的方向とイテレーション番号を割り当てます。これにより、並列エージェント間での概念重複を防げます。

---

4. 継続的 Claude PR ループ

本番レベルのシェルスクリプト で、継続的なループで Claude Code を実行し、PR を作成し、CI を待機し、自動マージします。AnandChowdhary により作成（謝辞：@AnandChowdhary）。

コアループ

┌─────────────────────────────────────────────────────┐
│  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     │
└─────────────────────────────────────────────────────┘

インストール

curl -fsSL https://raw.githubusercontent.com/AnandChowdhary/continuous-claude/HEAD/install.sh | 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

イテレーション間コンテキスト：SHARED_TASK_NOTES.md

重要な革新：イテレーション間で永続化される SHARED_TASK_NOTES.md ファイル：

## 進捗
- [x] 認証モジュールテスト追加（ラウンド 1）
- [x] トークンリフレッシュ内のエッジケース修正（ラウンド 2）
- [ ] 未完了：レート制限テスト、エラーバウンダリテスト

## 次のステップ
- 次はレート制限モジュールに焦点
- `tests/helpers.ts` のテストモック設定は再利用可能

Claude はイテレーション開始時にこのファイルを読み込み、イテレーション終了時に更新します。これにより、独立した claude -p 呼び出し間のコンテキストギャップが埋められます。

CI 失敗からの回復

PR チェックが失敗した場合、継続的 Claude は自動的に：

1. gh run list で失敗した実行 ID を取得
2. CI 修正コンテキストを備えた新しい claude -p を生成
3. Claude が gh run view 経由でログを確認、コード修正、コミット、プッシュ
4. チェック再待機（最大 --ci-retry-max 回の試行）

完了シグナル

Claude は魔法フレーズを出力して「完了した」とシグナルできます：

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

連続 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）

---

5. スロッピネス除去パターン

任意のループへの付加パターン。 各実装者ステップ後に、専用のクリーンアップ/リファクタリングステップを追加します。

問題

LLM に TDD で実装するよう要求する場合、「テスト作成」の理解が過度に文字通り：

• TypeScript 型システムが機能することを検証するテスト（typeof x === 'string' をテスト）
• 型システムで既に保証されているものについての過度に防御的な実行時チェック
• フレームワーク動作をテストするが、ビジネスロジックでない
• 実際のコードを隠す過度なエラーハンドリング

なぜ否定指令を使わないのか？

実装者プロンプトで「型システムをテストしないでください」または「不要なチェックを追加しないでください」を追加すると、下流効果が生じます：

• モデルはすべてのテストに関して躊躇するようになる
• 正当なエッジケーステストをスキップする
• 品質が予測不可能に低下

ソリューション：別のステップ

実装者を制限する代わりに、徹底させます。その後、焦点を絞ったクリーンアップエージェントを追加：

# 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."

ループコンテキストで

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

重要なインサイト

下流品質への影響を持つ否定指令を追加する代わりに、別のスロッピネス除去ステップを追加してください。2 つの焦点を絞ったエージェントの方が 1 つの制約されたエージェントより優秀です。

---

6. Ralphinho / RFC 駆動の DAG オーケストレーション

最も複雑なパターン。 RFC 駆動の複数エージェントパイプラインで、仕様を依存関係 DAG に分解し、階層的品質パイプラインを通じて各ユニットを実行し、エージェント駆動のマージキューで着陸させます。enitrat により作成（謝辞：@enitrat）。

アーキテクチャ概要

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  │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
└──────────────────────────────────────────────────────┘

RFC 分解

AI が RFC を読み込み、ワークユニットを生成：

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";
}

分解ルール：

• より少ない、結合度の高いユニットに傾斜（マージリスク最小化）
• ユニット間のファイル重複を最小化（競合回避）
• テストと実装を一緒に保つ（決して「X を実装」+ 「X をテスト」に分けない）
• 実際にコード依存関係が存在する場合にのみ依存関係を設定

依存関係 DAG が実行順序を決定：

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

複雑度階層

異なる階層は異なる深度のパイプラインを取得：

階層	パイプラインステージ
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	品質ゲート（大型階層のみ）

重要な設計： レビュー者は決して自身がレビューするコードを作成しません。これにより著者バイアスが除去されます——自己レビューで問題が見落とされる最も一般的な理由です。

駆逐機能付きマージキュー

品質パイプライン完了後、ユニットはマージキューに入ります：

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

ファイル重複インテリジェンス：

• 重複しないユニットは推測的に並列で着陸
• 重複するユニットは逐次的に着陸、毎回リベース

駆逐回復： 駆逐される時、完全なコンテキスト（競合ファイル、差分、テスト出力）が捕捉され、次の Ralph ラウンドの実装者にフィードバック：

## マージコンフリクト — 次のプッシュ前に解決

以前の実装は、別のユニットによって先にプッシュされたものとコンフリクトしました。
以下のコンフリクトファイル/行を避けるようにあなたの変更をリファクタリングしてください。

{完全な駆逐コンテキストと差分}

ステージ間のデータフロー

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)

ワークツリー隔離

各ユニットは隔離されたワークツリーで実行（git ではなく jj/Jujutsu を使用）：

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

同じユニットのパイプラインステージは 1 つのワークツリーを共有、research → plan → implement → test → review 間で状態を保持（コンテキストファイル、計画ファイル、コード変更）。

重要な設計原則

1. 決定論的実行 — 事前分解が並列性と順序をロック
2. レバレッジポイントで手動レビュー — 作業計画は単一の最高レバレッジ介入ポイント
3. 関心の分離 — 各ステージは独立したコンテキストウィンドウで、独立したエージェントが担当
4. コンテキスト付き競合回復 — 完全な駆逐コンテキストが盲目的な再試行ではなく賢い再試行をサポート
5. 階層駆動の深度 — 些細な変更は research/review をスキップ；大型変更が最大審査を取得
6. 回復可能なワークフロー — 完全な状態が SQLite に永続化；任意のポイントから回復可能

Ralphinho vs より単純なパターンの使用時期

シグナル	Ralphinho を使用	より単純なパターンを使用
複数の相互依存作業ユニット	はい	いいえ
並列実装が必要	はい	いいえ
マージコンフリクトの可能性	はい	いいえ（順序で OK）
シングルファイル変更	いいえ	はい（順序パイプライン）
複数日プロジェクト	はい	可能（継続-claude）
仕様/RFC が