要件明確化スキル

説明

100点スコアリングシステムを用いた体系的な明確化を通じて、曖昧な要件を実行可能なPRDに自動的に変換します。

指示

このスキルが呼び出されたら、曖昧な要件を検出してください：

1. 曖昧な機能リクエスト

   • ユーザーが言う：「ログイン機能を追加して」「決済を実装して」「ダッシュボードを作成して」
   • 不足している情報：どのように、どの技術で、どの制約があるか？

2. 技術コンテキストの欠落

   • 技術スタックが明記されていない
   • 統合ポイントが特定されていない
   • パフォーマンス/セキュリティ制約がない

3. 仕様の不完全性

   • 受け入れ基準がない
   • 成功指標がない
   • エッジケースが検討されていない
   • エラーハンドリングが言及されていない

4. スコープの曖昧性

   • 境界が不明確（「ユーザー管理」具体的には何か？）
   • MVPと今後の拡張の区別がない
   • 「含まれないもの」が明記されていない

アクティブ化しないケース：

• 特定のファイルパスが言及されている場合（例：「auth.go:45」）
• コードスニペットが含まれている場合
• 既存の関数/クラスが参照されている場合
• 明確な再現手順があるバグ修正の場合

コア原則

1. 体系的な質問

   • 焦点を絞った具体的な質問をする
   • 1ラウンドにつき1カテゴリー（2～3問）
   • 前の回答の上に構築する
   • ユーザーを圧倒しない

2. 品質駆動型の反復

   • 継続的に明確さスコア（0～100）を評価する
   • ギャップを体系的に特定する
   • スコアが90以上になるまで反復する
   • すべての明確化ラウンドを文書化する

3. 実行可能な出力

   • 具体的な仕様を生成する
   • 測定可能な受け入れ基準を含める
   • 実行可能なフェーズを提供する
   • 直接実装を可能にする

明確化プロセス

ステップ1：初期要件分析

入力：ユーザーの要件説明

タスク：

1. コア要件を解析して理解する
2. 機能名を生成する（ケバブケース形式）
3. ドキュメントバージョンを決定する（ユーザーが指定しない場合はデフォルト 1.0）
4. ./docs/prds/ が存在することを確認する（PRD出力用）
5. 初期明確さ評価を実施する（0～100）

評価ルーブリック：

機能的明確さ：30点満点
- 入出力が明確：10点
- ユーザーインタラクション定義済み：10点
- 成功基準記述済み：10点

技術的具体性：25点満点
- 技術スタック言及済み：8点
- 統合ポイント特定済み：8点
- 制約が具体化：9点

実装の完全性：25点満点
- エッジケース検討済み：8点
- エラーハンドリング言及済み：9点
- データ検証が具体化：8点

ビジネスコンテキスト：20点満点
- 問題ステートメント明確：7点
- ターゲットユーザー特定済み：7点
- 成功指標定義済み：6点

初期対応フォーマット：

ご要件を理解いたしました。この仕様の精緻化をお手伝いさせます。

**現在の明確さスコア**：X/100

**明確な側面**：
- [明確な点をリストアップ]

**明確化が必要な側面**：
- [不足している点をリストアップ]

これらの点を体系的に明確化させていただきます...

ステップ2：ギャップ分析

4つの次元でミッシング情報を特定します：

1. 機能スコープ

• コア機能は何か？
• 境界は何か？
• スコープ外は何か？
• エッジケースは何か？

2. ユーザーインタラクション

• ユーザーはどのように操作するか？
• 入力は何か？
• 出力は何か？
• 成功/失敗シナリオは何か？

3. 技術的制約

• パフォーマンス要件は？
• 互換性要件は？
• セキュリティの考慮事項は？
• スケーラビリティのニーズは？

4. ビジネス価値

• これが解決する問題は？
• ターゲットユーザーは？
• 成功指標は？
• 優先度は？

ステップ3：対話的な明確化

質問戦略：

1. 影響度が最も高いギャップから始める
2. 1ラウンドにつき2～3問を質問する
3. 段階的にコンテキストを構築する
4. ユーザーの言葉を使用する
5. 必要に応じて例を提供する

質問フォーマット：

PRD完成のため、以下の点を明確化させていただく必要があります：

1. **[カテゴリー]**：[具体的な質問]?
   - 例：[必要に応じて例を記載]

2. **[カテゴリー]**：[具体的な質問]?

3. **[カテゴリー]**：[具体的な質問]?

ご回答いただければ、PRDの精緻化を続けてまいります。

各ユーザー回答後：

1. 明確さスコアを更新する
2. 新しい情報を作業中のPRDアウトラインにキャプチャする
3. 残っているギャップを特定する
4. スコア < 90の場合：次のラウンドの質問を続行する
5. スコア ≥ 90の場合：PRD生成に進む

スコア更新フォーマット：

追加情報をありがとうございます！

**明確さスコア更新**：X/100 → Y/100

**新たに明確化されたコンテンツ**：
- [新しい情報をまとめる]

**明確化が残っている点**：
- [残っているギャップをリストアップ]

[スコア < 90の場合：次のラウンドの質問を続行]
[スコア ≥ 90の場合：「完璧です！これより完全なPRDドキュメントを生成いたします...」]

ステップ4：PRD生成

明確さスコアが90以上になったら、包括的なPRDを生成します。

出力ファイル：

1. 最終PRD：./docs/prds/{feature_name}-v{version}-prd.md

「Write」ツールを使用してこのファイルを作成または更新します。{version} はPRDに記録されたドキュメントバージョンから派生させます（デフォルト 1.0）。

PRDドキュメント構造

# {機能名} - 製品要件書（PRD）

## 要件説明

### 背景
- **ビジネス上の課題**：[解決すべきビジネス課題を説明]
- **ターゲットユーザー**：[ターゲットユーザーグループ]
- **価値提案**：[この機能がもたらす価値]

### 機能概要
- **コア機能**：[メイン機能のリスト]
- **機能の範囲**：[含まれるもの、含まれないもの]
- **ユーザーシナリオ**：[典型的な利用シナリオ]

### 詳細要件
- **入出力**：[具体的な入出力仕様]
- **ユーザーインタラクション**：[ユーザー操作フロー]
- **データ要件**：[データ構造と検証ルール]
- **エッジケース**：[エッジケースのハンドリング]

## 設計上の決定

### 技術的アプローチ
- **アーキテクチャの選択**：[技術アーキテクチャの決定と根拠]
- **主要コンポーネント**：[主要な技術コンポーネントのリスト]
- **データストレージ**：[データモデルとストレージソリューション]
- **インターフェース設計**：[API/インターフェース仕様]

### 制約
- **パフォーマンス要件**：[応答時間、スループットなど]
- **互換性**：[システム互換性要件]
- **セキュリティ**：[セキュリティの考慮事項]
- **スケーラビリティ**：[将来の拡張を見据えた考慮]

### リスク評価
- **技術的リスク**：[潜在的な技術リスクと軽減計画]
- **依存関係リスク**：[外部依存関係と代替案]
- **スケジュールリスク**：[タイムラインリスクと対応戦略]

## 受け入れ基準

### 機能的受け入れ
- [ ] 機能1：[具体的な受け入れ条件]
- [ ] 機能2：[具体的な受け入れ条件]
- [ ] 機能3：[具体的な受け入れ条件]

### 品質基準
- [ ] コード品質：[コード基準とレビュー要件]
- [ ] テストカバレッジ：[テスト要件とカバレッジ]
- [ ] パフォーマンス指標：[パフォーマンステスト合格基準]
- [ ] セキュリティレビュー：[セキュリティレビュー要件]

### ユーザー受け入れ
- [ ] ユーザーエクスペリエンス：[UX受け入れ基準]
- [ ] ドキュメンテーション：[ドキュメント提供要件]
- [ ] トレーニング資料：[必要に応じて、トレーニング資料要件]

## 実行フェーズ

### フェーズ1：準備
**目標**：環境準備と技術検証
- [ ] タスク1：[具体的なタスク説明]
- [ ] タスク2：[具体的なタスク説明]
- **成果物**：[フェーズの成果物]
- **期間**：[推定期間]

### フェーズ2：コア開発
**目標**：コア機能の実装
- [ ] タスク1：[具体的なタスク説明]
- [ ] タスク2：[具体的なタスク説明]
- **成果物**：[フェーズの成果物]
- **期間**：[推定期間]

### フェーズ3：統合・テスト
**目標**：統合と品質保証
- [ ] タスク1：[具体的なタスク説明]
- [ ] タスク2：[具体的なタスク説明]
- **成果物**：[フェーズの成果物]
- **期間**：[推定期間]

### フェーズ4：デプロイ
**目標**：リリースと監視
- [ ] タスク1：[具体的なタスク説明]
- [ ] タスク2：[具体的なタスク説明]
- **成果物**：[フェーズの成果物]
- **期間**：[推定期間]

---

**ドキュメントバージョン**：1.0
**作成日**：{timestamp}
**明確化ラウンド数**：{clarification_rounds}
**品質スコア**：{quality_score}/100

行動ガイドライン

すべきこと

• 具体的で焦点を絞った質問をする
• 前の回答の上に構築する
• ユーザーをガイドするために例を提供する
• 会話体のトーンを保つ
• PRD内に明確化ラウンドをまとめる
• 明確で専門的な英語を使用する
• 具体的な仕様を生成する
• スコアが90以上になるまで明確化モードを保つ

してはいけないこと

• すべての質問を一度に質問する
• 確認なしに仮定する
• スコアが90以上でないうちにPRDを生成する
• 必須セクションをスキップする
• 曖昧または抽象的な言語を使用する
• ユーザーの応答なしに進める
• スキルモードを早期に終了する

成功基準

• 明確さスコア ≥ 90/100
• すべてのPRDセクションが実質的に完成している
• 受け入れ基準がチェックリスト化可能（- [ ] 形式を使用）
• 実行フェーズが具体的なタスクで実行可能である
• ユーザーが最終PRDを承認している
• 開発チームへのハンドオフの準備ができている