zombies

ZOMBIES

Arguments

未加工の引数：$ARGUMENTS

引数が指定されている場合は、自由記述の機能説明として扱います（例：「サインインコードによるログインフロー」、「画像アップロードのバリデーション」）。Grep／Glob を使って、関連するコードとテストを自分で特定してください。

引数が空の場合は、git diff main...HEAD を実行し、その差分を機能の範囲として使用してください。

Goal

ZOMBIES を思考ツールとして使用し、その機能で作成する価値が最も高いテストを特定します。出力するのは、ユーザーが自分でひな形を作成できるテスト案のリストです。テストの作成やひな形の記述は行わないでください。

ZOMBIES は次の項目を表します。

• Zero — 入力なし／空の状態
• One — 単一の入力／正常系
• Many — 複数の入力、順序、ページネーション、並行処理
• Boundaries — 制限、境界値、最小／最大の長さ、タイミングの境界、型の境界
• Interface — パブリック API の契約／形式（戻り値の型、ステータスコード、リダイレクト）
• Exceptions — 無効な入力、失敗、期限切れ／使用済み／存在しない状態、認証の失敗
• Simple scenarios — 実際のユーザーが日常的に行う一般的な利用経路

該当しないカテゴリは省略してください。読み取り専用エンドポイントには「Many」に該当する項目がない場合があります。純粋なバリデーターには「Interface」に該当する項目がない場合があります。本当に作成する価値のあるテストだけを挙げてください。網羅性よりも品質を重視します。

Instructions

1. 機能を特定する

• 引数がある場合：Grep／Glob を使って、説明に一致するファイルをコードベースから検索します。実装ファイル（コントローラー、モデル、アクション、バリデーター）と、既存のテストファイルがあればそれも読みます。
• 引数がない場合：git diff --name-status main...HEAD と git diff main...HEAD を実行してから、変更された実装ファイルを読みます。自動生成ファイル（ロックファイル、コンパイル済みアセット、生成されたルート／型定義）は除外します。

2. ZOMBIES の提案を生成する

ZOMBIES の各文字について、「ここに、実際のバグを検出したり実際の動作を記録したりできるテストはあるか？」と考えます。あれば挙げ、なければ省略します。

既存のテストファイルと照合してください。 このスキルが出力するのは、作成すべきテストであり、カバレッジ一覧ではありません。そのため、次の点に従います。

• 既存のテストで十分にカバーされている動作は省略します。 カバー済みの動作は、作成すべきテストではありません。それを挙げると、重要な不足が埋もれてしまいます。
• 一部しかカバーされていない動作は残します。テストでは動作を確認していても、重要なアサーションが不足している場合（例：ログイン成功後のリダイレクトを確認しているが、コードが使用済みになることは確認していないなど）です。その箇条書きの先頭に [partial] を付け、不足しているアサーションを明記します。
• テストで動作がカバーされているか判断できない場合は、その箇条書きを残してください。誤って「カバー済み」と判断して省略すると、実際の不足が気づかれないままになります。

提案の品質基準：

• 具体的にし、一般論を避けます。 「境界値をテストする」よりも、「メールアドレスの最大長（255 文字）をテストする」の方が適切です。
• 可能な場合は、コード内の実際の値を参照します。例：マイグレーションで定義されたカラムの長さ、設定ファイルの有効期限、FormRequest のバリデーションルール。
• 箇条書き 1 つにつきテストを 1 つ挙げます。「A と B をテストする」のようにまとめないでください。
• メソッド名ではなく、検証すべき動作として記述します。「期限切れのサインインコードは 422 を返す」は、「test_expired_code」より適切です。

3. レポートを出力する

差分が複数の機能を対象としている場合は、まず機能領域ごとに分類し、その中で ZOMBIES の各文字ごとに分類します。**文字は必ず ZOMBIES の順序（Zero、One、Many、Boundaries、Interface、Exceptions、Simple）で表示します。**文字を省略しても、残りの順序は変わりません。表示する文字は、固定された順序で上から並べてください（たとえば、Zero、One、Many をすべて省略した場合でも、Boundaries、Interface、Exceptions の順に表示します）。次の形式を厳守してください。

## 🧟 [Feature Area]

**Boundaries**
- Email field rejects values longer than 255 chars (matches migration column)
- Sign-in code expires exactly at the 15-minute mark

**Exceptions**
- Expired code returns a validation error
- Already-used code cannot be redeemed twice
- Submitting code for an unknown email fails silently (no user enumeration)

**Simple**
- Requesting a code emails the user and creates a `SignInCode` row
- [partial] valid code logs the user in — existing test asserts the redirect but never asserts the code is consumed

🧟 接頭辞と ## レベルによって機能見出しが太字の **Letter** 小見出しと区別されます。両方を維持してください。対象となる機能が複数ある場合は、機能ごとにブロックを繰り返し、各ブロックを --- の水平線で区切って境界が明確になるようにしてください。

最後に、1 行の要約を記載します：X test ideas.

テストする価値のあるものがない場合（たとえば、単純な名称変更や設定のみの変更）は、次の内容だけを出力してください。

✅ Nothing worth writing tests for.

ルール

• **テストのスタブを作成しないでください。**このスキルが出力するのはアイデアのみです。テストはユーザーが作成します。
• 該当しない ZOMBIES の文字は省略してください。「（なし）」などのプレースホルダーは記載しないでください。網羅性より品質を重視してください。
• **未対応の箇所のみ扱ってください。**既存のテストですでに完全に網羅されている動作は省略します。一部しか網羅されていない動作は、未確認のアサーションを明記して [partial] を付けます。判断に迷った場合は、その箇条書きを残してください。実際にある未対応箇所を黙って省略してはいけません。
• **ZOMBIES の順序を必ず守ってください。**表示するセクションは Zero → One → Many → Boundaries → Interface → Exceptions → Simple の順に並べます。文字を省略しても構いませんが、残りの順序を変えてはいけません。
• **機能領域ごとに、文字ごとの見出しは 1 つだけにしてください。**各 ZOMBIES の文字は、機能領域内で最大 1 回のみ登場します。その文字に該当する箇条書きは、1 つの見出しの下にまとめてください。同じ文字の見出しを繰り返してはいけません。
• **具体的に記載してください。**コードにある実際の長さ、時間、ステータス、ルート名を参照してください。一般的な提案には価値がありません。
• **箇条書き 1 つにつき、動作は 1 つにしてください。**2 つのテストを「そして」でつないではいけません。
• **実装方法を示唆しないでください。**アサーション、ファクトリー、テストのセットアップを提案せず、確認する内容だけを記載してください。
• **まず機能ごとに分類し、その後に文字ごとに分類してください。**差分が複数の機能にまたがる場合、すべてを 1 つの巨大な ZOMBIES リストにまとめてはいけません。
• 前置きは不要です。「提案するテストは以下のとおりです」などとは書かず、最初の ## [Feature Area] 見出しから始めてください。
• 締めくくりのアドバイスは書かず、最後に X test ideas. の要約行だけを記載してください。