test-first-discipline

テストファーストの規律

内部共有スキルです。失敗するテストを先に行う実装順序の唯一の情報源です。ホストはこれを dependencies で宣言し、欠落している場合は処理を中断します。暗黙のフォールバックはありません。

名前に関する注意： 外部スキルリポジトリの名前と重複しないよう、意図的に tdd や test-driven-development という名前にはしていません。この名前のみを使用してください。

鉄則

最初に失敗するテストを確認せずに、本番の動作コードを書いてはいけません。

1. 失敗するテスト（または同等の自動化された失敗チェック）を書きます。
2. 実行し、現在のセッションで失敗を確認します。
3. テストを通すための最小限の本番コードを書きます。
4. 再実行し、その後、必要であればテストが成功した状態を保ちながらリファクタリングします。

手順 2 より前に本番の動作コードを書いていた場合は、そのコードを削除し、失敗するテストからやり直してください。「参考」として残したり、「テストを書きながら調整」したりしてはいけません。

適用対象

適用対象： 新機能、バグ修正、動作に影響するリファクタリング。

例外（ユーザーから別途指示がない限り）：

• 使い捨てのプロトタイプ
• 生成コード
• テスト対象の動作を含まない純粋な設定
• 純粋なドキュメント
• ユーザーが明示的にスキップを指示し、理由を簡潔に記録する場合

例外またはユーザーのスキップ指示がないのに、「今回だけスキップする」と正当化することは禁止されています。

test-suite-ensure との違い

スキル	担当範囲
test-first-discipline	順序 — 本番の動作コードより先にテストを失敗させる
test-suite-ensure	事後対応 — 既存のロジックに対して、スタックの検出、スキャフォールドの作成、カバレッジの生成／実行を行う

test-suite-ensure の実行が成功しても、このスキルに準拠したことを報告してはいけません。両方を使用するホストでは、動作を実装する際はテストファーストに従い、その後、ギャップやスキャフォールドへの対応として test-suite-ensure を呼び出します（ホストに応じて推奨または必須）。

禁止事項

• 事後に test-suite-ensure を実行しただけで、テストファーストに準拠したと主張すること
• このリポジトリ内で、このスキルの名前を tdd / test-driven-development に変更またはエイリアス化すること
• 例外またはユーザーのスキップ指示がないのに、通常の動作変更で失敗を確認する手順を省略すること

統合ガイド

• ホスト：実行ステージに、動作変更ではこのスキルを読み込むこと、およびタスク完了後の確認手順として test-suite-ensure を別途維持することを一行で記載してください。
• user-invocable: false を推奨します。ユーザーは PDCA ホスト経由で利用します。
• completion-evidence-discipline と組み合わせます。失敗（およびその後の成功）を確認した実行は、レッド／グリーンを主張する際に新しいエビデンスでなければなりません。