analyze

ユーザー入力

$ARGUMENTS

空でない場合は、先に進む前にユーザー入力を必ず考慮してください。

目標

実装に着手する前に、3つの中核的な成果物（spec.md、plan.md、tasks.md）における不整合、重複、曖昧さ、仕様不足の項目を特定します。このスキルは、bb-tasks スキルによって完全な tasks.md が正常に作成された後にのみ実行しなければなりません。

実行上の制約

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

憲章の優先性：プロジェクト憲章（プロジェクトルートまたは docs/ ディレクトリにある constitution.md）は、この分析の範囲内で変更不可です。憲章との矛盾は自動的に重大（CRITICAL）と判断し、原則を弱めたり、再解釈したり、黙って無視したりするのではなく、仕様、計画、またはタスクを修正する必要があります。原則自体を変更する必要がある場合は、このスキルの範囲外で、独立した明示的な憲章の更新として行わなければなりません。

実行手順

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

現在のフィーチャーディレクトリを特定し、必要なドキュメントが存在することを確認します。絶対パスを導出します。

• 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]
• 参照されているファイルパス

憲章から：

• 原則を検証するため、プロジェクトルートまたは docs/ ディレクトリにある constitution.md を読み込みます。

3. 意味モデルの構築

内部表現を作成します（生の成果物は出力に含めません）。

• 要件の一覧：各機能要件および非機能要件に、安定したキーを付与します（命令形の句を基にスラッグを導出します。例：「ユーザーがファイルをアップロードできる」→ user-can-upload-file）。
• ユーザーストーリー／アクションの一覧：受け入れ基準を伴う個別のユーザーアクション。
• タスクの対応付け：各タスクを1つ以上の要件またはストーリーに対応付けます（キーワード、または ID やキーフレーズなどの明示的な参照パターンから推定します）。
• 憲章のルールセット：原則名と MUST／SHOULD の規範的な記述を抽出します。

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

重要度の高い指摘に絞ります。指摘は最大50件とし、超過分は概要にまとめます。

A. 重複の検出

• 類似した要件の重複を特定します。
• 統合対象として、記述の質が低い方を示します。

B. 曖昧さの検出

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

C. 仕様不足

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

D. 憲章との整合性

• MUST 原則に反する要件または計画要素を指摘します。
• 憲章で必須とされているセクションや品質ゲートの欠落を指摘します。

E. 網羅性の不足

• 対応するタスクが1つもない要件を特定します。
• 対応する要件／ストーリーがないタスクを特定します。
• タスクに反映されていない非機能要件（性能、セキュリティなど）を特定します。

F. 不整合

• 用語の揺れ（同じ概念がファイルによって異なる名称で表現されている）
• 計画で参照されているデータエンティティが仕様にない（またはその逆）
• タスクの順序に矛盾がある（例：依存関係の記載がないまま、基盤設定タスクより先に統合タスクがある）
• 要件が競合している（例：一方では Next.js が必要とされ、もう一方では Vue が指定されている）

5. 重大度の割り当て

次の基準を使って、指摘事項の優先順位を付けます。

• CRITICAL：憲章の MUST に違反している、中核となる仕様成果物が欠けている、またはベースライン機能を妨げるカバレッジがゼロの要件
• HIGH：要件の重複または競合、セキュリティ／パフォーマンス属性の曖昧さ、テスト不可能な受け入れ基準
• MEDIUM：用語の揺れ、非機能タスクのカバレッジ不足、詳細が不足しているエッジケース
• LOW：スタイル／表現の改善、実行順序に影響しない軽微な重複

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

次の構成で Markdown レポートを出力します（ファイルへの書き込みは行いません）。

仕様分析レポート

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

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

カバレッジ概要表：

要件キー	タスクあり？	タスク ID	注記

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

対応付けられていないタスク：（該当する場合）

指標：

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

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

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

• CRITICAL の問題がある場合：bb-implement スキルを使う前に解決することを推奨します
• LOW／MEDIUM のみの場合：ユーザーは作業を続行できますが、改善案を提示します
• 具体的な提案を示します。例：「改良のために bb-specify スキルを実行する」「アーキテクチャを調整するために bb-plan スキルを実行する」「'performance-metrics' のカバレッジを追加するために tasks.md を手動で編集する」

8. 修正案を提示する

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

運用原則

コンテキストの効率化

• 重要度の高い情報を最小限に：網羅的な説明ではなく、実行可能な指摘に焦点を当てます
• 段階的な開示：成果物は段階的に読み込みます。分析内容をすべて一度に出力しないでください
• トークン効率の高い出力：指摘事項の表は50行までに制限し、超過分は要約します
• 決定論的な結果：変更がなければ、再実行しても一貫した ID と件数を出力します

分析ガイドライン

• ファイルを変更しないでください（読み取り専用の分析です）
• 存在しないセクションを捏造しないでください（存在しない場合は、その事実を正確に報告します）
• 憲章違反を優先してください（該当する場合は常に CRITICAL です）
• 網羅的なルールではなく、例を使ってください（一般論ではなく、具体的な事例を挙げます）
• 問題がゼロの場合も適切に報告してください（カバレッジ統計を含む正常終了レポートを出力します）

コンテキスト

{ARGS}