echo "a dvd bouncing tui" > idea.md と書いて dotpowers.dot にランナーを向ければ、テスト済みでレビュー済みのプロジェクトがgitブランチに仕上がって戻ってくる。DOTファイル1本、約1300行。superpowers開発メソドロジーをパイプライングラフとしてエンコードしたもので、ブレインストーミング、計画立案、TDD実装、マルチモデルレビュー、リリース判断をすべて失敗ハンドリングとヒューマンゲートで結線している。
インストール
git clone https://github.com/2389-research/dotpowers.git
attractor準拠のDOTランナーで実行する:
mkdir my-project && cd my-project
echo "a terminal dashboard that shows system metrics" > idea.md
git init
# tracker, mammoth, smasher — whatever you have
tracker /path/to/dotpowers.dot --tui
何をするのか
アイデアからリリース判断まで6フェーズ。 Brainstormはアイデアを読んで質問を一つずつ行い(YAGNIを強制)、2〜3種類のアーキテクチャアプローチを含む設計ブリーフを書き上げる。PlanはGPT-5.2がTDDプランを下書きし、シェルスクリプトが曖昧なステップを弾き、Opusがブリーフに照らしてすべての要件を監査する(最大5回繰り返し)。Setupはフィーチャーブランチを作りdepsをインストール。Implementはタスクごとにこの繰り返し: 失敗するテスト、最小限のコード、仕様レビュー(Opus)、品質レビュー(GPT-5.4)、コミット。Reviewは3つのモデルが独立してプロジェクト全体をレビューし、互いに相手の2件をクロス批評(6件)、Opusが最終判断を下す。Shipではローカルマージ、PRのプッシュ、ブランチ保持、破棄のどれかを選ぶ。
4つのモデル、それぞれ得意なことに集中。 Opus 4.6が仕様監査、合意形成、デバッグを担う。GPT-5.4がコードを書く。GPT-5.2がプランを下書き・修正する。Gemini 3.5 Flashがレビューで3番目の意見を出す。
段階的な失敗ハンドリング。 何かが壊れたとき、パイプラインはあなたに聞く前に4つのことを試みる: ノードを再試行(最大2回)、根本原因分析を含むデバッグ調査の実行、修正されたアプローチでのタスク再計画、そしてヒューマンゲートへのエスカレーション。ループ上限でトークンの浪費を防ぐ — プラン検証は5回、実装レビューはタスクごとに5回、最終修正は2サイクルまで。
ヒューマン・イン・ザ・ループ、ヒューマン・オン・ザ・フックではない。 あなたは設計ブリーフを承認する。3タスク完了ごとにバッチチェックポイントをレビューする。リリース方法を決める。実装側が質問があれば一時停止して聞く。それ以外のゲート間はパイプラインがヘッドレスで動く。
仕組み
パイプラインは単一のGraphviz DOTファイルだ。各ノードはLLMプロンプト(CSSライクなスタイルシートでモデルを割り当て)、シェルスクリプト(フォーマット検証、カウンター管理、ビルド検証)、またはヒューマンゲート(設計承認、バッチレビュー、リリース判断)のいずれか。エッジには成功・失敗のルーティング、ループバック、エスカレーションパスが含まれる。
状態は2か所に存在する: docs/plans/ にLLMが読み書きする成果物(ブレインストームメモ、設計ブリーフ、TDDプラン、監査結果)、.tracker/ にパイプラインの機構(ループカウンター、バッチ数、チェックポイントデータ)。plansディレクトリはコミットされ、trackerディレクトリはgitignoreされる。
ファンアウトノードが最終レビュー3件を並列実行する。ファンインノードがクロス批評前に結果を集約する。コンセンサスノードがすべてのレビューと批評を読んで、ship・rework・failのどれかにルーティングする。
