speckit-analyze

speckit-analyze

このスキルの内容は、GitHub Spec Kit の公式プロンプトテンプレートに基づいています。

• 上流：https://github.com/github/spec-kit
• ライセンス：MIT License, Copyright GitHub, Inc.（全文は同じディレクトリの LICENSE.txt を参照）
• 適応に関する説明：公式テンプレートはスラッシュコマンドの使用を想定しています。原文の $ARGUMENTS は、ユーザーが会話で提示するリクエストを指します。 コマンド間の参照（speckit.plan など）は、このスキル体系では同名の speckit-* スキルに対応します。 それ以外の内容は上流と同一で、書き換えは行っていません。

---

ユーザー入力

$ARGUMENTS

ユーザー入力が空でない場合は、処理を進める前に必ず考慮してください。

実行前チェック

拡張フックを確認します（分析の前）：

• プロジェクトのルートに .specify/extensions.yml が存在するか確認します。
• 存在する場合は読み込み、hooks.before_analyze キー以下のエントリを確認します。
• YAML を解析できない場合、または無効な場合は、黙ってスキップしてはいけません。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録されている必須（optional: false）フックも含め、フックを確認していないことをユーザーに伝えたうえで、通常どおり続行します。
• enabled が明示的に false のフックを除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、condition 式を解釈または評価しようとしてはいけません。
  • フックに condition フィールドがない場合、または null／空の場合は、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• 実行可能な各フックについて、optional フラグに基づき、以下を出力します。
  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意の事前フック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張フック
    
    **自動事前フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    
    目標に進む前に、フックコマンドの結果を待ってください。
    

    上記のブロックを出力した後、続行する前に、必ずフックを実際に呼び出し、完了するまで待つ必要があります。このエージェント／セッションでコマンドを実行するのと同じ方法で実行します（呼び出し方法は、上記に表示された {command} の ID と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... または $speckit-... のように実行します）。ブロックを出力しただけでは、フックを実行したことにはなりません。
• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何も出力せずにスキップします。

目標

実装前に、3 つの主要な成果物（spec.md、plan.md、tasks.md）全体の矛盾、重複、曖昧さ、仕様不足の項目を特定します。このコマンドは、__SPECKIT_COMMAND_TASKS__ が完全な tasks.md の生成に成功した後にのみ実行しなければなりません。

実行上の制約

厳密に読み取り専用：ファイルを変更してはいけません。構造化された分析レポートを出力します。修正計画を任意で提示してもかまいません（その後に手動で編集コマンドを実行する場合、ユーザーの明示的な承認が必要です）。

憲章の優先性：プロジェクト憲章（/memory/constitution.md）は、この分析の範囲内では交渉の余地がありません。憲章との矛盾は自動的に重大（CRITICAL）とみなされ、憲章の原則を弱めたり、再解釈したり、黙って無視したりするのではなく、仕様、計画、またはタスクを調整する必要があります。原則自体を変更する必要がある場合は、__SPECKIT_COMMAND_ANALYZE__ の外部で、憲章を別途明示的に更新しなければなりません。

実行手順

1. 分析コンテキストの初期化

リポジトリのルートから {SCRIPT} を 1 回実行し、JSON を解析して FEATURE_DIR と AVAILABLE_DOCS を取得します。絶対パスを導出します。

• SPEC = FEATURE_DIR/spec.md
• PLAN = FEATURE_DIR/plan.md
• TASKS = FEATURE_DIR/tasks.md

必須ファイルが存在しない場合は、エラーメッセージを表示して中止します（不足している前提コマンドを実行するようユーザーに指示します）。 "I'm Groot" のように引数にシングルクォートが含まれる場合は、エスケープ構文を使用します。例：'I'''m Groot'（可能であればダブルクォートでもかまいません）。

2. アーティファクトを読み込む（段階的な開示）

各アーティファクトから必要最小限のコンテキストのみを読み込みます。

spec.md から：

• 概要／コンテキスト
• 機能要件
• 成功基準（パフォーマンス、セキュリティ、可用性、ユーザーの成功、ビジネスへの影響など、測定可能な成果）
• ユーザーストーリー
• エッジケース（記載がある場合）

plan.md から：

• アーキテクチャ／技術スタックの選択
• データモデルへの参照
• フェーズ
• 技術的制約

tasks.md から：

• タスク ID
• 説明
• フェーズごとのグループ分け
• 並列化マーカー [P]
• 参照されているファイルパス

constitution から：

• /memory/constitution.md を読み込み、原則への準拠を検証します

3. セマンティックモデルを構築する

内部表現を作成します（出力には生のアーティファクトを含めないでください）。

• 要件一覧：各機能要件（FR-###）と成功基準（SC-###）について、安定したキーを記録します。明示的な FR-/SC- 識別子がある場合はそれを主キーとして使用し、読みやすさのために任意で命令形のフレーズからスラッグを作成します（例：「ユーザーはファイルをアップロードできる」→ user-can-upload-file）。実装可能な作業を必要とする成功基準項目のみを含めます（例：負荷テスト用のインフラ、セキュリティ監査ツール）。リリース後の成果指標やビジネス KPI（例：「サポートチケットを 50% 削減する」）は除外します。
• ユーザーストーリー／アクション一覧：受け入れ基準を伴う個別のユーザーアクション
• タスクの網羅性マッピング：各タスクを 1 つ以上の要件またはストーリーに対応づけます（キーワードや ID、キーフレーズなどの明示的な参照パターンから推測します）。
• Constitution のルールセット：原則名と MUST／SHOULD に関する規範的な記述を抽出します。

4. 検出パス（トークン効率を重視した分析）

重要度の高い指摘に焦点を当てます。指摘は合計 50 件までとし、残りは概要にまとめます。

A. 重複の検出

• 重複に近い要件を特定します
• 統合のため、表現の品質が低いものに印を付けます

B. 曖昧さの検出

• 測定可能な基準がない曖昧な形容詞（高速、スケーラブル、安全、直感的、堅牢など）を指摘します
• 未解決のプレースホルダー（TODO、TKTK、???、<placeholder> など）を指摘します

C. 仕様不足

• 動詞はあるものの、目的語または測定可能な成果が欠けている要件
• 受け入れ基準との整合性が欠けているユーザーストーリー
• spec／plan で定義されていないファイルやコンポーネントを参照するタスク

D. Constitution との整合性

• MUST 原則に反する要件または plan の要素
• Constitution で義務づけられているセクションや品質ゲートの欠落

E. 網羅性のギャップ

• 対応するタスクが 1 件もない要件
• 対応する要件／ストーリーがないタスク
• 実装可能な作業を必要とする成功基準（パフォーマンス、セキュリティ、可用性）がタスクに反映されていないケース

F. 不整合

• 用語の揺れ（同じ概念がファイル間で異なる名称になっている）
• plan で参照されているものの spec にないデータエンティティ（またはその逆）
• タスクの順序に関する矛盾（依存関係の記載がないまま、基盤のセットアップタスクより先に統合タスクが配置されている場合など）
• 要件の競合（例：一方では Next.js を求め、他方では Vue を指定している）

5. 重要度の割り当て

指摘の優先順位付けには、次の目安を使用します。

• CRITICAL：Constitution の MUST に違反している、主要な spec アーティファクトが欠落している、または基本機能を妨げる網羅性ゼロの要件
• HIGH：要件の重複または競合、曖昧なセキュリティ／パフォーマンス属性、テスト不可能な受け入れ基準
• MEDIUM：用語の揺れ、非機能要件に関するタスクの網羅性不足、仕様が不十分なエッジケース
• LOW：スタイルや表現の改善、実行順序に影響しない軽微な重複

6. 簡潔な分析レポートを作成する

ファイルへの書き込みは行わず、次の構成で Markdown レポートを出力します。

仕様分析レポート

ID	カテゴリ	重大度	場所	概要	推奨事項
A1	重複	HIGH	spec.md:L120-134	類似した要件が2つあります ...	表現を統合し、より明確な方を残してください

（検出事項ごとに1行追加してください。カテゴリの頭文字を接頭辞にした、安定した ID を生成してください。）

カバレッジ概要テーブル：

要件キー	タスクあり？	タスク ID	備考

憲章との整合性に関する問題：（ある場合）

マッピングされていないタスク：（ある場合）

メトリクス：

• 要件の総数
• タスクの総数
• カバレッジ率（1つ以上のタスクがある要件の割合）
• 曖昧さの数
• 重複の数
• 重大な問題の数

7. 次のアクションを提示する

レポートの最後に、簡潔な「次のアクション」ブロックを出力してください。

• CRITICAL な問題がある場合：__SPECKIT_COMMAND_IMPLEMENT__ の前に解決することを推奨します
• LOW／MEDIUM の問題のみの場合：作業を進めてもかまいませんが、改善案を提示してください
• 具体的なコマンドを提示してください。例：「改良を加えて SPECKIT_COMMAND_SPECIFY を実行する」、「アーキテクチャを調整するために SPECKIT_COMMAND_PLAN を実行する」、「『performance-metrics』をカバーするように tasks.md を手動で編集する」

8. 修正案を提示する

ユーザーに次のように尋ねてください：「上位 N 件の問題について、具体的な修正案を提示しましょうか？」（自動で適用しないでください。）

9. 拡張フックを確認する

レポートの出力後、プロジェクトのルートに .specify/extensions.yml が存在するか確認してください。

• 存在する場合は読み込み、hooks.after_analyze キーの下にある項目を確認してください
• YAML を解析できない、または無効な場合は、黙ってスキップしないでください。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録された必須（optional: false）フックを含め、フックを一切確認していないことをユーザーに伝え、そのまま通常どおり続行してください
• enabled が明示的に false のフックを除外してください。enabled フィールドのないフックは、デフォルトで有効として扱ってください。
• 残りの各フックについて、condition 式を解釈または評価しないでください。
  • condition フィールドがない場合、または値が null／空の場合は、実行可能なフックとして扱ってください
  • 空ではない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねてください
• 実行可能な各フックについて、optional の値に応じて次のように出力してください。
  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意のフック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張フック
    
    **自動フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

    上記のブロックを出力した後、続行する前に必ずフックを実際に呼び出し、完了するまで待機してください。エージェント／セッションでコマンドを実行する場合と同じ方法で実行してください（呼び出し方法は、表示されている {command} の ID と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... または $speckit-... として実行します）。ブロックを出力するだけでは、フックは実行されません。
• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何も出力せずスキップしてください

運用原則

コンテキスト効率

• 最小限の高シグナルなトークン：網羅的な説明ではなく、実行可能な指摘に集中してください
• 段階的な情報開示：アーティファクトを少しずつ読み込み、内容をすべて一度に出力しないでください
• トークン効率の高い出力：検出事項の表は50行までとし、それを超える分は要約してください
• 決定論的な結果：変更がない状態で再実行した場合、一貫した ID と件数を出力してください

分析ガイドライン

• ファイルを絶対に変更しないでください（これは読み取り専用の分析です）
• 欠落しているセクションを絶対に捏造しないでください（存在しない場合は、正確に報告してください）
• 憲法違反を優先してください（これらは常に重大です）
• 網羅的なルールより例を優先してください（一般的なパターンではなく、具体的な箇所を示してください）
• 問題がゼロの場合は適切に報告してください（カバレッジ統計を含む成功レポートを出力してください）

コンテキスト

{ARGS}