tdd-cyclelisted

# テスト駆動のサイクル **失敗するテスト → 通す最小実装 → 整理** を 1 単位として進める。NDF ではこの Skill を テスト駆動の唯一の基準とし、他の Skill から重複した規則を持たせない。 ## 同じリリースで追加する Skill（本文の `※` 印） 本文で `※` を付けた Skill 名は同じリリースで順次追加されるものであり、まだ配布物に 存在しないことがある。**見つからない場合は探し回らず、下表の代替でそのまま進める。** | Skill | 参照している内容 | 未追加のあいだの代替 | | --- | --- | --- | | `requirements-design` | 受け入れ条件の作り方 | 受け入れ条件を「観測可能・一意・テスト可能」な 1 文へ自分で書き下す | | `refactoring` | 構造改善と現状固定テスト | サイクル内の整理にとどめ、構造改善は別タスクへ切り出す | | `quality-gates` | 全体テストの実行とカバレッジ閾値の判定 | 対象プロジェクトのカバレッジツール設定に従い、設定がなければ測定値の記録だけ行う | ## 適用しない対象 次の変更にテスト駆動を強制しない。テストを書けないのではなく、書いても振る舞いを 担保しないためである。 | 対象 | 代わりに行うこと | | --- | --- | | ドキュメント・コメント | リンクと手順の実行可能性を確認する | | 静的な設定値・定数の変更 | 設定が読まれる経路を 1 度実行して確認する | | 生成物（ビルド出力・lockfile・自動生成コード） | 生成コマンドを再実行して差分が一致することを確認する | | 依存パッケージの版更新のみ | 既存テストを実行する | 判断に迷う場合は「この変更で壊れうる振る舞いがあるか」で決める。あるなら適用する。 ## 事前調査（サイクルに入る前に 1 度だけ） プロジェクト固有のテスト手段を先に確定させる。推測でコマンドを組み立てない。 ```bash # 例: どこにテストがあり、どう起動するか ls tests/ test/ spec/ 2>/dev/null grep -n '"test"' package.json 2>/dev/null grep -n '\[tool.pytest' pyproject.toml 2>/dev/null cat Makefile 2>/dev/null | grep -n '^test' ``` 確定させる項目: | 項目 | 例 | | --- | --- | | テスト実行コマンド | `pytest`、`npm test`、`go test ./...` | | 単一テストの絞り込み方 | `pytest -k name`、`npm test -- -t name` | | テストの置き場所と命名 | `tests/test_*.py`、`src/**/*.test.ts` | | 既存のテストダブルの流儀 | fixture / factory / モックライブラリ | 既存テストがそもそも通らない場合は、**先にそれを報告する**。壊れた状態を基準にすると、 自分の変更が原因かどうかを切��分けられない。 ## サイクル ### 1. 失敗するテストを書く 受け入れ条件 1 つに対してテスト 1 つを書く（条件の作り方は `requirements-desig