checklist

チェックリストの目的: 「要件文章のユニットテスト」

重要な概念: チェックリストは要件記述のユニットテストです。特定のドメインにおける要件の品質、明確さ、完全性を検証します。

実装テストではない:

• ❌ 「ボタンが正しくクリックできることを確認」
• ❌ 「エラーハンドリングが動作することをテスト」
• ❌ 「APIが200を返すことを確認」
• ❌ コード/実装が仕様に一致するかのチェック

要件品質の検証:

• ✅ 「すべてのカードタイプに視覚的階層要件が定義されているか？」（完全性）
• ✅ 「'目立つ表示'が具体的なサイズ/位置で定量化されているか？」（明確さ）
• ✅ 「すべてのインタラクティブ要素でホバー状態要件が一貫しているか？」（一貫性）
• ✅ 「キーボードナビゲーションのアクセシビリティ要件が定義されているか？」（カバレッジ）
• ✅ 「ロゴ画像読み込み失敗時の動作が仕様に定義されているか？」（エッジケース）

メタファー: 仕様が英語で書かれたコードなら、チェックリストはそのユニットテストスイートです。要件が適切に書かれ、完全で、曖昧でなく、実装準備が整っているかをテストします。実装が動作するかではありません。

ユーザー入力

$ARGUMENTS

空でない場合、続行する前にユーザー入力を考慮する必要があります。

実行手順

1. セットアップ

{SCRIPT} をリポジトリルートから実行し、JSONから FEATURE_DIR と AVAILABLE_DOCS を取得。

• シングルクォートを含む引数は適切にエスケープ

2. 意図の明確化（動的）

ユーザーの表現 + spec/plan/tasks から抽出したシグナルに基づいて、最大3つの文脈的な明確化質問を導出:

質問生成アルゴリズム:

1. シグナル抽出: 機能ドメインキーワード（auth, latency, UX, API等）、リスク指標（critical, must, compliance）、ステークホルダーヒント（QA, review, security team）、明示的成果物（a11y, rollback, contracts）
2. シグナルを候補フォーカス領域にクラスタリング（最大4、関連性順）
3. 対象者とタイミング（author, reviewer, QA, release）を推測
4. 欠落ディメンションを検出: スコープ範囲、深度/厳密性、リスク強調、除外境界、測定可能な受け入れ基準
5. 以下のアーキタイプから質問を選択:
   • スコープ精緻化
   • リスク優先順位付け
   • 深度調整
   • 対象者フレーミング
   • 境界除外
   • シナリオクラスギャップ

質問形式ルール:

• オプション提示時はコンパクトな表: オプション | 候補 | 重要な理由
• 最大A〜Eオプション
• ユーザーが既に述べたことを再度聞かない

デフォルト（対話不可時）:

• 深度: 標準
• 対象者: コード関連ならレビューワー、それ以外は著者
• フォーカス: 上位2つの関連クラスタ

3. リクエスト理解

$ARGUMENTS + 明確化回答を組み合わせ:

• チェックリストテーマを導出（security, review, deploy, ux等）
• ユーザーが言及した必須項目を統合
• フォーカス選択をカテゴリスキャフォールドにマッピング
• spec/plan/tasks から不足コンテキストを推測（捏造しない）

4. 機能コンテキスト読み込み

FEATURE_DIR から:

• spec.md: 機能要件とスコープ
• plan.md（あれば）: 技術詳細、依存関係
• tasks.md（あれば）: 実装タスク

コンテキスト読み込み戦略:

• アクティブなフォーカス領域に関連する部分のみ読み込み
• 長いセクションは簡潔なシナリオ/要件箇条書きに要約
• 段階的開示: ギャップ検出時のみ追加取得

5. チェックリスト生成

「要件のユニットテスト」を作成:

1. FEATURE_DIR/checklists/ ディレクトリを作成（なければ）
2. ユニークなファイル名を生成:
   • ドメインに基づく短い説明的な名前（例: ux.md, api.md, security.md）
   • 形式: [domain].md
   • ファイルが存在すれば追記
3. CHK001から連番
4. 各項目に参照（Spec/Plan/Tasks）または [Gap] [Ambiguity] を付与