Custom agent imported from t1nyb0x/slack-emoji-bulk-inserter (
.github/agents/speckit.analyze.agent.md). Copyright stays with the author.
---
description: spec.md、plan.md、tasks.md の各成果物に対して、非破壊的なクロスアーティファクト整合性・品質分析を実行します。
---
## ユーザー入力
```text
$ARGUMENTS以下に進む前に、ユーザー入力を必ず考慮してください（空でない場合）。
目標
3つのコアアーティファクト（spec.md、plan.md、tasks.md）全体の不整合、重複、曖昧さ、未定義項目を実装前に特定します。このコマンドは /speckit.tasks が完全な tasks.md を正常に生成した後にのみ実行してください。
操作制約
厳密に読み取り専用: ファイルを一切変更しないでください。構造化された分析レポートを出力します。任意の修正計画を提案できますが（ユーザーが明示的に承認してから、手動でフォローアップ編集コマンドを実行する必要があります）。
コンスティテューション準拠: プロジェクトコンスティテューション（.specify/memory/constitution.md）はこの分析範囲内で交渉不可です。コンスティテューションとの矛盾は自動的にCRITICALとなり、仕様・計画・タスクの調整が必要です。原則の希薄化、再解釈、暗黙的な無視は許容されません。原則自体を変更する必要がある場合は、/speckit.analyze の外で別途明示的にコンスティテューション更新を行ってください。
実行ステップ
1. 分析コンテキストの初期化
リポジトリルートから .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks を一度実行し、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'（または可能であればダブルクォート: "I'm Groot"）。
2. アーティファクトの読み込み（段階的開示）
各アーティファクトから最小限必要なコンテキストのみを読み込みます：
spec.md から:
- 概要/コンテキスト
- 機能要件
- 非機能要件
- ユーザーストーリー
- エッジケース（存在する場合）
plan.md から:
- アーキテクチャ/技術スタック選択
- データモデル参照
- フェーズ
- 技術的制約
tasks.md から:
- タスクID
- 説明
- フェーズグループ
- 並列マーカー [P]
- 参照ファイルパス
コンスティテューションから:
.specify/memory/constitution.mdを読み込み、原則の検証に使用
3. セマンティックモデルの構築
内部表現を作成します（出力に生のアーティファクトを含めないでください）：
- 要件インベントリ: 各機能要件 + 非機能要件に安定したキーを付与（命令形フレーズからスラグを導出。例: 「ユーザーがファイルをアップロードできる」→
user-can-upload-file） - ユーザーストーリー/アクションインベントリ: 受け入れ基準付きの個別ユーザーアクション
- タスクカバレッジマッピング: 各タスクを1つ以上の要件またはストーリーにマッピング（キーワード/明示的な参照パターン（IDやキーフレーズ）による推論）
- コンスティテューションルールセット: 原則名とMUST/SHOULDの規範的記述を抽出
4. 検出パス（トークン効率的分析）
高シグナルの検出に集中します。検出件数は合計50件に制限し、残りはオーバーフローサマリーに集約します。
A. 重複検出
- 類似した要件を特定
- 低品質な表現を統合候補としてマーク
B. 曖昧性検出
- 測定可能な基準のないあいまいな形容詞（高速、スケーラブル、安全、直感的、堅牢）にフラグを立てる
- 未解決のプレースホルダー（TODO、TKTK、???、
<placeholder>など）にフラグを立てる
C. 未定義検出
- 動詞はあるが対象や測定可能な結果がない要件
- 受け入れ基準との整合が不足しているユーザーストーリー
- spec/planで定義されていないファイルやコンポーネントを参照しているタスク
D. コンスティテューション整合性
- MUST原則と矛盾する要件または計画要素
- コンスティテューションで義務付けられたセクションや品質ゲートの欠落
E. カバレッジギャップ
- 関連タスクがゼロの要件
- マッピングされた要件/ストーリーがないタスク
- タスクに反映されていない非機能要件（例: パフォーマンス、セキュリティ）
F. 不整合
- 用語のドリフト（同じ概念がファイル間で異なる名前で使用されている）
- planで参照されているがspecに存在しないデータエンティティ（またはその逆）
- タスク順序の矛盾（例: 依存関係の注記なしに基盤セットアップタスクより前に統合タスクがある）
- 矛盾する要件（例: 一方がNext.jsを要求し、他方がVueを指定している）
5. 重大度の割り当て
検出結果の優先順位付けに以下のヒューリスティックを使用します：
- CRITICAL: コンスティテューションのMUST違反、コアspecアーティファクトの欠落、またはベースライン機能をブロックするカバレッジゼロの要件
- HIGH: 重複または矛盾する要件、あいまいなセキュリティ/パフォーマンス属性、テスト不能な受け入れ基準
- MEDIUM: 用語のドリフト、非機能タスクカバレッジの欠落、未定義のエッジケース
- LOW: スタイル/表現の改善、実行順序に影響しない軽微な冗長性
6. コンパクトな分析レポートの作成
以下の構造でMarkdownレポートを出力します（ファイル書き込みなし）：
仕様分析レポート
| ID | カテゴリ | 重大度 | 場所 | 概要 | 推奨事項 |
|---|---|---|---|---|---|
| A1 | 重複 | HIGH | spec.md:L120-134 | 類似した2つの要件... | 明確な方の表現を残して統合 |
（検出ごとに1行追加。カテゴリ頭文字をプレフィックスとした安定したIDを生成。）
カバレッジサマリーテーブル:
| 要件キー | タスクあり？ | タスクID | 備考 |
|---|
コンスティテューション整合性の問題: （ある場合）
マッピングされていないタスク: （ある場合）
メトリクス:
- 総要件数
- 総タスク数
- カバレッジ率（1つ以上のタスクがある要件の割合）
- 曖昧性カウント
- 重複カウント
- CRITICALイシューカウント
7. 次のアクションの提供
レポートの最後に、簡潔な「次のアクション」ブロックを出力します：
- CRITICALイシューがある場合:
/speckit.implementの前に解決を推奨 - LOW/MEDIUMのみの場合: 続行可能だが改善提案を提示
- 具体的なコマンド提案を提供: 例「/speckit.specify で改善を実行」「/speckit.plan でアーキテクチャを調整」「tasks.md を手動編集して 'performance-metrics' のカバレッジを追加」
8. 修正の提案
ユーザーに尋ねます：「上位N件のイシューについて具体的な修正案を提案しましょうか？」（自動的に適用はしないでください。）
運用原則
コンテキスト効率
- 最小限の高シグナルトークン: 網羅的なドキュメントではなく、アクション可能な検出に集中
- 段階的開示: アーティファクトを段階的に読み込み、すべての内容を分析にダンプしない
- トークン効率的な出力: 検出テーブルを50行に制限。オーバーフローは要約
- 決定論的な結果: 変更なしで再実行した場合、一貫したIDとカウントが生成されるべき
分析ガイドライン
- ファイルを絶対に変更しない（読み取り専用分析）
- 欠落セクションをハルシネーションしない（存在しない場合は正確に報告）
- コンスティテューション違反を優先（常にCRITICAL）
- 網羅的なルールより具体例を使用（一般的なパターンではなく具体的なインスタンスを引用）
- ゼロイシューの場合は正常レポートを出力（カバレッジ統計付きの成功レポートを発行）
コンテキスト
$ARGUMENTS