spec-kit-checklist

変更成果物全体の要件品質を監査します。これは要件リンターであり、テストランナーではありません。

入力：変更名を任意で指定します。省略された場合は、コンテキストから推定するか、質問します。

手順

1. 成果物を読み込む

   specs/changes/<name>/ に存在するものを読み込みます：

   • spec.md、plan.md、tasks.md

   また、指針との整合性を確認するために FRAMEWORK.md も読み込みます。

2. 確認質問を最大3つ行う（コンテキストが明確な場合は省略）

   対象範囲、リスクの優先順位付け、対象読者、対象外とする境界に焦点を当てます。

3. 要件品質チェックリストを生成する

   specs/changes/<name>/checklists/ に、ドメインごとにグループ化したファイル（例：api.md、ux.md、security.md）を作成または更新します。

   各チェックリスト項目には、以下が必要です：

   • 質問形式を使用する：「[シナリオ] における [要件の側面] は定義されていますか？」
   • 品質の観点を示すタグを含める：[Completeness]、[Clarity]、[Consistency]、[Measurability]、[Gap]、[Ambiguity]、[Conflict]
   • 参照元を示す：[Spec §X] または [Plan §X]
   • 既存のチェックリスト ID と重複させない — 最後の CHK-N から番号を続ける

   対象とする品質の観点：

   • Completeness — すべてのシナリオとエッジケースが指定されていますか？
   • Clarity — 用語は曖昧さがなく、客観的に測定できますか？
   • Consistency — 要件同士が矛盾していませんか？
   • Measurability — 解釈に頼らず、成功基準を検証できますか？
   • Coverage — すべてのユーザーストーリーをタスクまで追跡できますか？
   • Non-functional — パフォーマンス、セキュリティ、規模に関する要件が含まれていますか？

   ❌ 禁止：「ボタンのクリックを確認する」「API が 200 を返すことをテストする」 — これらは実装テストです。 ✅ 必須：「X が失敗した場合のフォールバック動作は定義されていますか？」「『高速』を客観的に測定できますか？」

4. 報告する

   以下を含む概要を作成します：

   • 品質の観点ごとの項目数
   • 優先度の高いギャップ
   • spec-kit-plan または spec-kit-implement スキルへの移行を妨げる項目

ガードレール

• 既存のチェックリスト項目は削除せず、追記のみ行います。
• チェックリスト項目のトレーサビリティを80％以上に保ちます。
• FRAMEWORK.md の原則に関するギャップは CRITICAL として報告します。
• このスキルは要件を監査するものであり、コードの動作を監査するものではありません。