iterative-development

iterative-development skill の概要

iterative-development とは

iterative-development skill は、Claude Code で各モデル応答のあとにテストを実行し、失敗を Stop hook 経由で自動的にフィードバックするためのワークフローです。通常のプロンプトよりも厳密な TDD ループを回したいときに特に有効で、会話が終わる前に各パスを検証したい機能開発ではとくに向いています。

どんな人にインストール向きか

この iterative-development skill は、すでにテスト、lint、型チェックを日常的に使っていて、Claude にそれらが通るまで修正ループの中に留まってほしい開発者に合っています。Workflow Automation の構成とは相性がよい一方で、信頼できるテストコマンドがないプロジェクトや、各回答のあとに人手でレビューしたい場合には、あまり向いていません。

実務で重要になる理由

価値の中心は「プロンプトをうまくすること」ではなく、コード生成と検証のあいだのギャップを縮めることです。この skill は Claude に実際の失敗を見せて応答させるため、壊れた前提を早い段階で拾いやすくなり、一発実装の失敗を避けやすくなります。さらに、リポジトリが本当に受け付けない点だけに絞って反復できるので、改善の焦点を保ちやすくなります。

iterative-development skill の使い方

ワークフローファイルをインストールして場所を確認する

iterative-development install のリポジトリ導入フローを使ったら、まず SKILL.md を開いてください。この skill には補助スクリプトやサブフォルダがないため、動作ロジックのほとんどはその 1 ファイルに集約されています。最短で理解したいなら、他のものより先に SKILL.md を読むのが近道です。

テスト可能な作業指示から始める

iterative-development usage のパターンは、プロンプトに具体的な成果物、関連ファイル、そしてループで実行してほしい検証コマンドを明記したときに最も効果を発揮します。たとえば、「src/auth/ でパスワードリセットの検証を追加し、既存の API 形状は維持したまま、各パスのあとに npm test と npm run lint を実行する」のような指示が有効です。「auth を改善して」のような曖昧な依頼よりも、hook が検証できる決定的な対象を持てるぶん優れています。

依存する前に hook ロジックを読む

iterative-development guide では、Stop hook がどのように終了するか、stderr がどう Claude に返るか、TDD ループが各ターンで何を確認するかを説明している箇所に注目してください。これらは、ワークフローが本当に反復するのか、それとも失敗したコマンドのあとに止まるだけなのかを左右する重要部分です。リポジトリに Python 版が含まれている場合は、別の環境へそのまま持ち込む前に、シェル構成と比較してください。

検証が安く、繰り返しやすい場面で使う

最適なのは、フィードバックが速いタスクです。ユニットテスト、lint ルール、型チェック、小規模な統合テストなどがそれに当たります。逆に、曖昧な調査タスク、繰り返せるコマンドのない単発デバッグ、あるいは「正解」をチェック可能な失敗として表現できないプロジェクトでは使わないほうがよいでしょう。

iterative-development skill FAQ

iterative-development は TDD 専用ですか？

いいえ。TDD との相性は良いですが、本質的に必要なのは、すばやく失敗し、Claude に何を直すべきかを伝えられる、反復可能な検証コマンドです。明確な合否判定があるなら、コード変更、リファクタリング、整理作業にも使えます。

通常のプロンプトと何が違いますか？

通常のプロンプトでは、コードを 1 回生成して検証は人間が行うことがあります。iterative-development skill は、自動的な停止と修正のサイクルを追加するため、Claude はテスト失敗をすぐに見て、セッションが終わる前に修正できます。Workflow Automation では、単に「テストも書いて」と指示するだけより、こちらのほうが信頼性が高くなります。

初心者にも使いやすいですか？

はい、すでにテストの実行方法と失敗ログの読み方を知っているなら使いやすいです。一方で、プロジェクトのツールチェーンを学んでいる途中なら、初心者向けとは言いにくくなります。というのも、この skill は信頼できるチェックコマンドを自分で特定し、なぜ失敗したのかを理解できる前提で動くからです。

どんなときに使うべきではありませんか？

テストが不安定、E2E チェックが遅い、あるいはコード変更と無関係なノイズの多い失敗を出すコマンドしかない場合は使わないでください。そのような状況では、ループが時間を浪費したり、Claude が本質的でない修正を繰り返してしまい、実際の解決にたどり着けなくなることがあります。

iterative-development skill の改善方法

ループにより明確な制約を与える

品質を大きく上げる一番の方法は、最初に正確なコマンド、ファイル、受け入れ条件を指定することです。「動くようにして」ではなく、何が通る必要があるのか、何を変えてはいけないのか、どの失敗を決定的とみなすのかを明示してください。そうすることで、iterative-development skill が迷走せず、狙った修正に収束しやすくなります。

失敗結果を読み取りやすくする

テスト出力が長い、フレークする、あるいは曖昧だと、Claude に入るフィードバックの質が下がります。検証経路を短くし、失敗するコマンドを切り分け、エラーの面積を小さくすることで、skill 自体を改善できます。短く明快に失敗するテスト 1 本のほうが、理由の違う失敗を出す広範なチェック 3 本よりも有用です。

1 回目の結果を受けてプロンプトを反復する

最初の出力が惜しいが正確ではない場合は、その差分を具体的に追記してください。「テストは通ったが、hook では npm run typecheck も実行してほしい」「実装を変えても公開 API は維持してほしい」のように書くのが有効です。最初からやり直すより、この skill は各サイクルで 1 つの精密な制約を足していくほうがうまく働きます。

ループを壊す典型的なミスに注意する

よくある失敗は、きれいに終了しないコマンドを使うこと、自動検証できない目標を頼むこと、リポジトリ本来のテスト起点を省略することです。ループが止まったように見える場合は、タスクを単純化し、Claude に権威あるテストコマンドを明示し、Stop hook が stderr を通じて失敗を返す設定になっているか確認してください。