ループエンジニアリングだと？？ no.2

前回、「Loop Engineering（ループエンジニアリング）」をお試しするためのワークスペースを準備中に5h制限に非掛かってしました。
その続きです。

単純すぎる名前のワークスペースLoopEngineeringWS/
ここにsuperpowers@claude-plugins-officialの助けを得ながらルールを整備していました。

レビュー洩れの対応

1点、レビュー指摘洩れがあったのでその点を指摘して直してもらってます。

## レビューループ(ゲート3)
5. 対象は `src/` のコード変更。ドキュメントのみの変更はレビュー省略可

この部分は、以下の通り修正しました。

## レビューループ(ゲート3)
5. 対象は `src/`, `tests/`のコード変更およびドキュメントを対象とし、ユーザが省略して良いと伝えない限りレビューを実施すること

「Loop Engineering（ループエンジニアリング）」のコアはこれですかね。

生成された「.claude\skills\dev-loop\SKILL.md」

.claude\skills\dev-loop\SKILL.md

---
name: dev-loop
description: src/ のコード変更を伴う開発タスクの標準ループ。成功基準定義→TDD実装→品質ゲート→独立2レビュアー→すり合わせ→完了報告。開発タスクを受けたら必ず使用する。テストコード・設計ドキュメント類の変更も独立2レビュー(§3〜§4)の対象。
---

# 開発ループ

## 1. 成功基準の定義

タスクを検証可能な成功基準(箇条書き)に変換し、ユーザーに提示してから着手する。
PROJECT-SPEC.md を先に読む。曖昧な要求は着手前に質問する。

## 2. TDD実装

superpowers:test-driven-development に従う(Red→Green→Refactor)。
ゲート1(編集直後の構文/整形/静的解析)とゲート2(ターン終了前の全テスト)はフックが自動実行する。
- 「⚠ Docker未起動」警告を見たら `docker compose up -d php` の上、scripts/lint.ps1・analyse.ps1・test.ps1 で該当ゲートを手動再実行する。
- 「スタイル自動整形を適用した」と言われたファイルは次の編集前に再読込する。

## 3. 独立2レビュー(ゲート3)

ゲート1・2通過後:

1. `git diff HEAD` で差分全文を取得する
2. Agentツールで subagent_type: reviewer を **2インスタンス並列**起動する(1メッセージ内で2回呼ぶ)。
   両方に同一の入力を渡す: タスク内容と成功基準/差分全文/「PROJECT-SPEC.md を読め」という指示。
   互いの存在・出力には言及しない(独立性の維持)
3. 両方の結果が返ってから突き合わせに進む

## 4. すり合わせ

| 状況 | 扱い |
|---|---|
| 両者が同旨の指摘 | 確定。必ず修正する |
| 片方のみの指摘 | SendMessage でもう一方のレビュアーへ「次の指摘(引用)に同意するか。根拠付きで答えよ」と確認。同意→修正。不同意→実装者がコードで裏取りして判断(superpowers:receiving-code-review に従う。性急に同意しない) |
| low のみ | 修正は任意。見送る場合は完了報告に理由を書く |

修正したら、修正差分のみを両レビュアーへ SendMessage で再レビュー依頼する(新規起動しない)。
両者 APPROVE で収束。最大3ラウンド。収束しなければ争点を整理してユーザーにエスカレーションする。
レビュアーが起動失敗したら1回リトライし、それでも失敗なら単独レビューで続行して完了報告に警告を書く。

## 5. 完了報告

成功基準それぞれに達成/未達と根拠を示す。見送った low 指摘と理由、レビューのラウンド数を書く。

## 適用範囲

独立2レビュー(ゲート3)は既定。ユーザーが明示的に「1名でよい」と指示した場合に限り単独レビューにできる。

- src/ のコード変更を伴うタスク: このループ全体が必須
- テストコードの変更: 同上(src/ 配下でレビュー対象)
- 設計ドキュメント類(docs/ の spec・plan 等)の変更: TDD とゲート1・2は対象外だが、ゲート3のレビュー(§3〜§4)は必須(人数は上記の既定=独立2に従う)

また、たびたび5h制限で停止してしまうとちっとも「Loop Engineering（ループエンジニアリング）」にならないので、少しでも防止するために以下の様なトークン使用量の予測の仕組みを組んでみました。

/usageはClaudeCOde側からは叩けないので、作業の開始とリミット警告が出たタイミングで学習用に/usageの値を渡します。
ClaudeCodeではccusageを利用してセッション内での利用量と/usageの比較を記録させ、閾値辺りで新たな作業を行わない設定としています。
※まだうまくはいっていませんがｗ

「CLAUDE.md」

CLAUDE.md

# CLAUDE.md

## 原則(常に適用)

1. **Think Before Coding** — 前提を明示する。不確かなら着手前に質問する。
2. **Simplicity First** — 求められたものだけを最小限のコードで。単一用途に抽象を持ち込まない。
3. **Surgical Changes** — 変更する全行が要求に直結していること。ついで修正をしない。
4. **Goal-Driven** — 着手前に検証可能な成功基準を定義する。

## ワークスペースの掟

- 実行環境はDockerのみ。ホストでPHP/Composerを実行しない。
- テスト/Lint/静的解析は必ず `scripts/test.ps1|lint.ps1|analyse.ps1`(= コンテナ内 `composer test|lint|analyse`)経由。
- 品質ゲートはフックが強制する。「⚠ Docker未起動」警告を見たら `docker compose up -d php` を実行し、該当ゲートを scripts/ で手動再実行する。
- 「スタイル自動整形を適用した」と言われたファイルは、次の編集前に再読込する。
- `src/` のコード変更を伴うタスクは `dev-loop` スキルに従う(成功基準→TDD→ゲート→独立2レビュアー→すり合わせ)。
- 独立2レビューは既定。対象は `src/` のコード・テストコードと設計ドキュメント類(`docs/` の spec・plan 等)。ユーザーが明示的に「1名でよい」と指示した場合のみ単独レビューにできる。
- リリース物は `src/` 一式(vendor含む)。`src/` の外に実行時依存を置かない。
- 案件固有情報(FW・DB・ドメイン用語・規約)は `PROJECT-SPEC.md` を読む。
- コンテキスト効率を意識する。必要なファイルだけ読み、レビュアーには差分と関連ファイルのみ渡す。

## 稼働制限(Pro プラン・5時間枠)

- Pro プランには5時間のローリング利用枠があり、超過すると次回開放まで停止する。上限で作業を不用意に打ち切らない。
- 利用枠の逼迫を認識したら(ハーネスの上限警告、または `npx ccusage@20.0.17 claude blocks --active --json` で確認したアクティブな5時間ブロックの消費が**高水準=目安80%**)、新規の着手を止め、進行中の成果を安全な区切りでコミット等により保全し、**次回リミット開放まで待機**する。
- セッション開始時に利用・終了時に利用枠の状況を確認すること。`/usage` はユーザー操作でしか読めないため、ハーネスの警告・ccusage・ユーザーの合図を signal として運用する。
- 長時間の連続作業・`/loop` 実行時は、区切り(目安10分)ごとに利用状況を意識する。`/loop` 実行時は ScheduleWakeup のセルフペーシングで近似する。
- 補足(実装上の制約): 利用量は `ccusage`(ローカルログからの**近似**。公式の Pro 5時間枠とは一致しない)でオンデマンド取得できるが、公式%そのものを読む手段は無い(`/usage` はユーザー操作)。また「10分毎の自動確認・自動待機」を自走させる時間トリガは通常セッションに無く、`/loop` の ScheduleWakeup でのみ近似できる。本ルールはハーネスの警告・ccusage/`/usage`・ユーザーの合図を signal とした運用規約として扱う。

## 入口

- 案件の初期化(テンプレートコピー後に1回): `bootstrap` スキル
- 日常の開発タスク: `dev-loop` スキル

早速試してみる

特にいま作成したいものはないので、なんとなくpasskeyで認証を行うWebのデモサイトを作成してもらいましょう。
planをsuperpowers@claude-plugins-officialの助けを借りながらまとめてレビューを実施

plan-1～3の3フェースで計画されました。
詳細は省略します。

/loop plan-1

これで「Loop Engineering（ループエンジニアリング）」方式の開発ループが動き始め、実装計画→実装→２エージェントレビュー→テストコード生成→レビュー→テスト→コミットのサイクルが繰り返されます。
ただ、5hリミット計算のサンプルが少なすぎるのと判断粒度が荒いため直ぐにリミットにあたってしまいました
ここは本格的にAI中心＋適所で人による確認・選択を開発プロセスとするのであれば、上のプランで業務するとよさげですね。

なお、ユーザに問いを求める場合やレビューが収束しない場合などはLoopが停止しヒアリングされます。

バイブコーディングでもそうですが、
計画書の作成・レビュー、タスク分解・レビュー、開発・レビューを繰り返す。
結局はそれに尽きるのかなという感触でした。

plan-3の頃にはある程度5hリミット時の/usageとccusageの値の対比を学習して徐々にリミット前に作業を停止するようになってきました。

個人的な印象
都度指示するよりもかなり放置に近い感じで自律的に作業してくれますが…
決定的にでは開発プロセスをすべてこれにしよう！というほどには印象的な革命ではない感じでした。

しっかり計画を立てていればバイブコーディングのようにWBSを基に「この指示に従い実装して」でも同じかもしれません。
結局は「ハーネス」が肝ですよねー

リミットとの闘いの自律的な停止→再開は是非ものにしたいなぁと感じた「Loop Engineering（ループエンジニアリング）」体験でした

--

前回の記事