project-test-loop

/project:test-loop

このスキルを使う場面

次のような場合にこのスキルを使います	次のような場合は project-continue を使います
テストに合格するまで RED -> GREEN -> REFACTOR ループを進める	テストがボトルネックではない一般的なプロジェクト作業を再開する
自動修正・再試行の動作で失敗したテストを繰り返し実行する	完了したセッションからパターンを記録する場合は、代わりに project-distill を使います
--max-cycles で TDD の反復回数を制限し、ループの暴走を防ぐ	テストコマンド自体が不明な場合は、代わりに project-discovery を使います

自動化された TDD サイクル（テスト -> 修正 -> リファクタリング）を実行します。各反復では決定論的なドライバースクリプト（scripts/run-test-cycle.sh）が機械的な処理を行い、呼び出しの合間に最小限の修正を加えます。

コンテキスト

• プロジェクトマーカー：!find . -maxdepth 1 \( -name package.json -o -name pyproject.toml -o -name pytest.ini -o -name Cargo.toml -o -name go.mod -o -name Makefile \) -print

パラメーター

$ARGUMENTS から次の項目を解析します。

• test-pattern（位置指定、省略可） — 実行対象を絞り込むために、検出されたテストコマンドに渡すパターンです（例：ファイル、テスト名のフィルター）。
• --max-cycles <N>（省略可、既定値は 10） — ループの上限です。サイクル数が N に達すると、ドライバーは CAP_REACHED を返します。

プロジェクトのテストコマンドが CLAUDE.md / .claude/rules/ で設定されていて、自動検出される形式に該当しない場合は、ドライバーに --test-cmd "<command>" も渡して上書きします。

実行

この TDD ループを実行します。各反復では決定論的なドライバーを実行し、その後、返された VERDICT に応じて対応します。

Step 1: テストサイクルを 1 回実行する

ドライバーを呼び出します（上記のプロジェクトマーカーからテストコマンドを自動検出します。対象は package.json の test スクリプト、pytest / pyproject.toml、cargo test、go test、または Makefile の test: ターゲットです）。

bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --pattern "$0" --max-cycles 10

解析した test-pattern を --pattern に指定します（指定がない場合は省略）。解析した --max-cycles の値も指定します。構造化出力の VERDICT= 行と、上限付きの === TEST OUTPUT === の末尾を確認します。

Step 2: 判定結果に応じて分岐する

VERDICT	意味	対応
GREEN	テストコマンドが終了コード 0 で終了 — テストスイートに合格	Step 3（リファクタリング）に進み、その後停止します
CONTINUE	テストスイートは失敗しているが、上限には達していない	最小限の修正を行い（Step 2a）、Step 1 を繰り返します
STUCK	同じ失敗シグネチャが 3 サイクル続いている — 進展なし	停止し、障害要因を報告して入力を求めます
CAP_REACHED	サイクル数が --max-cycles に達した	停止し、残っている失敗を報告します
SETUP_ERROR	テストコマンドを検出または実行できなかった	停止し、テストの実行方法を尋ねるか、--test-cmd を指定して再実行します

Step 2a: 最小限の修正を行う（CONTINUE の場合）

=== TEST OUTPUT === の末尾を読み、失敗を特定します。

1. どのテストが失敗したか、期待値と実際の値を確認します。
2. 根本原因を特定します。実装の不足、誤った戻り値、未対応のエッジケース、統合上の問題などが考えられます。
3. コードに対して最小限の修正を行います。失敗したテストが必要とする部分だけを修正してください。テストに合格させるためにテストを編集しないでください。それでは、テストスイートという独立した判定者を、自己判定のループに変えてしまいます（「ループの健全性」を参照）。

その後、Step 1 を繰り返します。ドライバーはサイクルカウンターを増やして、再チェックします。

Step 3: GREEN の間にリファクタリングする（GREEN の場合）

テストスイートに合格したら、重複コード、マジックナンバー、長い関数、わかりにくい名前、複雑な条件分岐など、改善できる点を探し、動作を変えずにリファクタリングします。リファクタリングのたびに Step 1 を再実行し、テストスイートが引き続き GREEN であることを確認します。改善点がなくなったら、成功を報告して停止します。

Step 4: 報告する

実行したサイクル数、適用した修正、実施したリファクタリング、最終ステータス（すべて GREEN／理由と推奨される次のステップを添えてブロック中）を要約します。

ループの整合性

このループの停止条件はテストスイートそのものです。これは独立した機械的な判定者であり、どれだけ懸命に作業したかにかかわらず、テストが失敗すれば失敗と判定します。これはまさに .claude/rules/loop-integrity.md の柱 1 が求めているものです。ドライバースクリプトはその判定を決定論的なものにします。GREEN はあなたの意見ではなく、テストスイート自体の終了コード 0 を示します。--max-cycles の上限（CAP_REACHED）と、同じ失敗が 3 回続いた場合のルール（STUCK）が、無制限なループを防ぎます。テストを編集して合格させてはいけません。そうすると、独立した判定者が自己判定のループに変わってしまいます。

よくある失敗パターン

症状	修正（最小限）
undefined is not a function、NameError	不足している関数またはクラスを実装します。シグネチャとダミーの戻り値だけで十分です
Expected X but got Y	余計なロジックは追加せず、戻り値だけを修正します
特定の入力で失敗する	条件を 1 つだけ追加して、そのエッジケースに対処します
コンポーネント間の連携時に失敗する	コンポーネント全体ではなく、統合箇所を修正します

自動停止条件

すべてのテストに合格し、リファクタリングも残っていない場合（SUCCESS、GREEN）、STUCK（同じ失敗が 3 回続いた場合。ドライバーが進展なしと判断したことを示します）、CAP_REACHED（--max-cycles に到達）、SETUP_ERROR（テストコマンド自体の不具合、または検出不能）、あるいは修正方法が不明な場合（NEEDS USER INPUT）は、停止して報告します。

エージェント向けの最適化

コンテキスト	コマンド
1 サイクル、自動検出	bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --max-cycles 10
パターンを指定	bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --pattern "$0"
テストコマンドを上書き	bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --test-cmd "pytest -x -q"
新しいループを開始（サイクル状態をリセット）	bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --reset
判定を読み取る	bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --max-cycles 10 | grep -E '^VERDICT='