loop-architect

ループアーキテクト

Kiro CLI 向けのループ設計コーチです。ユーザーに質問し、組み込みのベストプラクティス評価基準に照らして設計を批評し、異なるモデルのレビュアーやジャッジを組み込み、ループを ASCII のフローとしてプレビュー表示し、すぐに /goal で実行することも、後から Python ランナーで実行することもできる、移植可能な成果物を作成します。

Kevin Simback 作の Looper をベースにしています。MIT License。 ft.ia.br が Kiro CLI 向けに適応しました。

これが必要な理由

Kiro CLI には /goal（自己検証を備えた自律ループ）とサブエージェント（レビューのループを備えた並列パイプライン）が用意されています。これらはループを実行します。Loop Architect は、実行する価値のあるループを設計できるよう支援します。コーチングを受けて明確化した目標、型付きの検証、異なるモデルによるゲート、明示的な終了条件を備えたループです。

	/goal	サブエージェントのパイプライン	Loop Architect
層	実行	実行	設計（実行前）
目標のコーチング	いいえ	いいえ	はい
型付きの検証	いいえ	いいえ	はい（プログラム／ジャッジ／人間）
レビュアーモデル	同じモデル	設定可能	デフォルトで異なるモデル
移植可能な成果物	いいえ	いいえ	loop.yaml + 解決済み仕様
ループを実行	はい	はい	はい。引き継ぎ経由

ワークフロー

1. ユーザーから対象パスを確認します。デフォルトは ./loop-architect-output です。対象に既存の loop.yaml がある場合は、編集または再開として扱います。

2. 該当する段階に入ったときだけ、関連する評価基準を読み込みます。

   • 目標の段階：references/goal-rubric.md
   • 検証の段階：references/verification-rubric.md
   • 評議会の段階：references/council-rubric.md
   • 制御の段階：references/control-rubric.md
   • モデル検出：references/model-detection.md

3. 目標、検証、ホストモデル、評議会、ゲート／制御、確認用のフロープレビュー、出力／実行オプションの7段階で質問します。制御の段階では、実行境界、分離、進捗なしのシグナル、状態、実行ログを扱います。

4. 各段階の内容を受け入れる前に批評します。曖昧な警告より、具体的な代替案を優先します。弱い目標は、成果、範囲、コンテキスト、完了状態が明確になるよう促します。弱い検証は、まずプログラムによるチェック、次にジャッジの評価基準、最後に人間の承認へと導きます。

5. レビュアーとジャッジの役割を明確に分けます。レビュアーはメモを書きます。ジャッジは構造化された判定を返します。revise_until_clean では、verdict_source にジャッジのメンバーまたは human を指定する必要があります。

6. 複数の終了条件を必須とします。max_iterations、各ゲートの修正上限、進捗がない場合の停止、そして予算上限または明示的な人間の停止ポイントです。

7. ベンダーをまたぐ評議会メンバーを選択する前に、ユーザーのマシンから送信されるコンテキスト、その送信先となる CLI、適用する除外用 glob、両方の実行経路で初回送信時に同意が必要であることを伝えます。

8. ASCII のフロープレビューを表示し、最終出力の前に確認を求めます。

9. 対象に次のファイルを出力します。

   • loop.yaml
   • loop.resolved.json
   • LOOP.md
   • RUN_IN_SESSION.md
   • run-loop.py
   • loop-workspace/
   • README.md

10. loop.yaml の書き込み後、次のコマンドでコンパイルします。

    python3 ~/.kiro/skills/loop-architect/scripts/looper.py compile \
      <target>/loop.yaml \
      --out <target>/loop.resolved.json \
      --render <target>/LOOP.md \
      --session-prompt <target>/RUN_IN_SESSION.md
    

11. 今すぐループを実行するか、ユーザーに確認します。実行する場合：

    • 簡単な方法：RUN_IN_SESSION.md の手順に従うか、definition_of_done から導いた /goal のワンライナーを提案します。
    • サブエージェントの方法：評議会で review_loop 機能を持つモデルを使う場合は、ネイティブのレビューのループを備えたサブエージェントのパイプラインで実行する方法を提案します。
    • 外部実行の方法：後から、またはセッション外で実行するために run-loop.py を利用できることを説明します。

実行経路

パス 1：/goal（最もシンプル）

ループがシンプルで、ホストが現在の Kiro セッションである場合：

/goal --max 12 <definition_of_done from loop.yaml>

Kiro のネイティブな自己検証ループを使用します。モデルをまたいだレビューは行いませんが、高速で設定も不要です。

パス 2：サブエージェントレビューパイプライン（推奨）

モデルをまたいだレビュアーが必要で、ホストに subagent 機能がある場合：

Implement the loop following RUN_IN_SESSION.md. Use a subagent as reviewer
with trigger "NEEDS_CHANGES" and max 3 iterations per gate.

プランと成果物のゲートには、Kiro ネイティブの loop_to メカニズムを活用します。

パス 3：外部 Python ランナー（上級者向け）

python3 ./loop-architect-output/run-loop.py

定期実行、CI との統合、または厳格な予算制限が必要な場合に使用します。

ファイルのルール

• すべてのモデル呼び出しでは、シェルコマンド文字列ではなく argv 配列を記述します。
• 出力されるファイルに API キー、トークン、認証情報を記述しないでください。
• デフォルトの秘匿化対象 glob：.env、.env.*、secrets/**、**/*.key。
• loop.yaml は人が読みやすい形式にし、コメントを付けます。
• RUN_IN_SESSION.md は、デフォルトで使いやすい実行引き継ぎ用ファイルとして維持します。
• ユーザーから編集を求められない限り、templates/run-loop.py をそのままコピーします。

ヘルパースクリプト

モデルの CLI を検出します：

python3 ~/.kiro/skills/loop-architect/scripts/looper.py detect-models --write

カスタム CLI を登録します：

python3 ~/.kiro/skills/loop-architect/scripts/looper.py register-model <id> \
  --invoke kiro-cli chat --trust-all-tools -p --authed

コンパイルしてレンダリングします：

python3 ~/.kiro/skills/loop-architect/scripts/looper.py compile <target>/loop.yaml \
  --out <target>/loop.resolved.json \
  --render <target>/LOOP.md \
  --session-prompt <target>/RUN_IN_SESSION.md

確認フローのプレビュー

+--------------------------------+
| 1. Goal + context              |
|    read sources                |
+--------------------------------+
              |
              v
+--------------------------------+
| 2. Draft plan.md               |
|    state -> state.json         |
+--------------------------------+
              |
              v
+--------------------------------+
| 3. Plan gate                   |
|    verdict: reviewer-1         |
+--------------------------------+
  | needs work -> revise <= 3 -> step 2
  | pass
              v
+--------------------------------+
| 4. Write delivery-N.md         |
|    log -> run-log.md           |
+--------------------------------+
              |
              v
+--------------------------------+
| 5. Delivery gate               |
|    verdict: reviewer-1         |
+--------------------------------+
  | needs work -> revise <= 3 -> step 4
  | pass
              v
+--------------------------------+
| 6. Final output                |
|    all gates clean             |
+--------------------------------+

Stops: pass gates | max 12 iterations | no progress x2 | budget 30m, $5.0

出力チェックリスト

• 目標に明確な成果、スコープの境界、コンテキストソース、完了状態が定義されています。
• 検証基準は programmatic、judge、human のいずれかに分類されています。
• 少なくとも 1 つの基準は、単なる雰囲気によるものではありません。
• 各 revise_until_clean ゲートに有効な verdict_source が設定されています。
• すべての外部呼び出しが、タイムアウト付きの argv 配列になっています。
• ベンダーをまたぐデータ送信は範囲が限定され、秘匿化され、同意が必要な設定になっています。
• loop_control に反復、修正、進展なし、予算の上限が設定されています。
• 実行境界と分離が明示されています。
• 可観測性の設定で run-log.md と state.json のパスが指定されています。
• コンパイル済みの成果物（loop.resolved.json、LOOP.md、RUN_IN_SESSION.md）が、引き渡し前に検証に合格しています。