Project Loop — OpenClaw向け軽量プロジェクトオーケストレーション
概要
Project Loopは、OpenClawエコシステム向けに作られた「承認済みで長期間続く作業」を扱うための軽量オーケストレーションスキルです。セッションのリセットや途中中断、承認ゲート、検証手順、そしてセッションが古くなった際の回復を前提としたワークフローを想定しており、プロジェクトファイル(manifest.mdやstate.json)を単一の信頼できる情報源として扱う設計が特徴です。短期の一回きりタスクやオープンエンドな自律実行には適さず、長時間にわたる明確な承認と検証が必要なケースに最適化されています。
リポジトリの統計情報
- スター数: 3
- フォーク数: 0
- ウォッチャー数: 3
- コミット数: 2
- ファイル数: 3
- メインの言語: 未指定
主な特徴
- 長期プロジェクトを前提とした耐久性のあるオーケストレーション(リセットや中断に耐える)
- プロジェクトファイルを単一の信頼できる情報源として扱う(state.json > manifest.md の優先順位)
- 承認ゲート、バリデーション、ポーズ/再開、回復フローのサポート
- 自己完了可能なタスク(self-clearable tasks)を組み込める設計
技術的なポイント
Project Loopのコア設計は「プロジェクト状態をファイルで管理し、外部要因による中断やリセットからの回復を保証する」点にあります。manifest.mdはプロジェクトの宣言的な記述を提供し、state.jsonはランタイムの真の状態を保持することで、再起動や別セッションからの参照時に一貫性を保ちます。「trust: state.json > manifest.md …」という階層は、実行時の実際の進行状況を優先することで競合や重複実行を避けるためのシンプルだが重要な方針です。
承認フローや検証ステップが重要な用途向けに、Project Loopはワークフローを小さな自己完了可能なタスク群に分割し、各タスクが完了状態でファイルに反映されることを想定しています。これにより、例えば担当者の承認待ちでセッションが切れても、次回起動時に未完了タスクのみを再開でき、二重実行や情報喪失のリスクを下げられます。さらにポーズ/再開機構は検証や外部依存(人の承認や外部システムの応答)を挟む長期ワークフローで有効です。
設計上は「リーン(軽量)」であることを重視しており、余計な自律判断や複雑な分散ロジックを持たせず、ファイルベースのシンプルなソースオブトゥルースに依存します。これにより実装・運用のコストが低く、検証もしやすくなります。ただし、このシンプルさは同時に制限でもあり、高度な並列実行制御や大規模な分散状態管理を必要とする用途には適していません。
リポジトリ自体は小規模で、README.mdとSKILL.mdで使い方やスキルの目的を説明し、LICENSEを添付する構成です。現状はプロトタイプに近く、運用で使う際はstateのバックアップ、マルチユーザー同時操作の対策、外部承認プロセスとの接続方法などの追加実装や運用ガイドが必要になるでしょう。OpenClawのプラットフォーム上で、明確な開始・停止・承認ポイントを持つ長期間タスクを安全に管理したいチームにとって、有力な出発点となります。
プロジェクトの構成
主要なファイルとディレクトリ:
- LICENSE: file
- README.md: file
- SKILL.md: file
まとめ
長期ワークフローの耐久性と承認を重視した、シンプルで実用的なオーケストレーションスキル。
リポジトリ情報:
- 名前: project-loop-skill
- 説明: Lean project orchestration skill for OpenClaw
- スター数: 3
- 言語: null
- URL: https://github.com/sebclawops/project-loop-skill
- オーナー: sebclawops
- アバター: https://avatars.githubusercontent.com/u/262026950?v=4
READMEの抜粋:
Project Loop
Lean orchestration skill for approved long-running work that must survive resets, interruption, approval gates, and stale sessions.
Use It When
- a project will outlast one session
- chat history is not enough
- work should continue through self-clearable tasks
- approvals, validation, pause/resume, and recovery matter
Do not use it for trivial one-turn tasks or open-ended autonomy.
Core Model
- project files are the source of truth
- trust:
state.json>manifest.md…