requirements-clarity

要件の明確化スキル

説明

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

手順

呼び出されたら、曖昧な要件を検出します:

1. 曖昧な機能要望

   • ユーザーの発言例: 「ログイン機能を追加して」「決済を実装して」「ダッシュボードを作成して」
   • 不足している情報: 実現方法、使用技術、制約条件

2. 技術的な文脈の欠如

   • 技術スタックの記載がない
   • 連携ポイントが特定されていない
   • パフォーマンスまたはセキュリティ上の制約がない

3. 仕様の不完全性

   • 受け入れ基準がない
   • 成功指標がない
   • エッジケースが考慮されていない
   • エラー処理の記載がない

4. スコープの曖昧さ

   • 境界が不明確（「ユーザー管理」とは具体的に何を指すのか）
   • MVPと将来の拡張機能の区別がない
   • 「対象外」の記載がない

次の場合は起動しないでください:

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

基本原則

1. 体系的な質問

   • 焦点を絞った具体的な質問をする
   • 一度に1つのカテゴリを扱う（1ラウンドあたり2〜3問）
   • 前の回答を踏まえて進める
   • ユーザーに負担をかけすぎない

2. 品質主導の反復

   • 明確度スコア（0〜100）を継続的に評価する
   • 不足点を体系的に特定する
   • 90点以上になるまで反復する
   • すべての確認ラウンドを記録する

3. 実行可能な成果物

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

明確化のプロセス

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

入力: ユーザーの要件記述

タスク:

1. 中核となる要件を解析して理解する
2. 機能名を生成する（kebab-case形式）
3. ドキュメントのバージョンを決定する（ユーザーが指定しない限りデフォルトは 1.0）
4. PRDの出力先として ./docs/prds/ が存在することを確認する
5. 初期の明確度評価（0〜100）を行う

評価基準:

Functional Clarity: /30 points
- Clear inputs/outputs: 10 pts
- User interaction defined: 10 pts
- Success criteria stated: 10 pts

Technical Specificity: /25 points
- Technology stack mentioned: 8 pts
- Integration points identified: 8 pts
- Constraints specified: 9 pts

Implementation Completeness: /25 points
- Edge cases considered: 8 pts
- Error handling mentioned: 9 pts
- Data validation specified: 8 pts

Business Context: /20 points
- Problem statement clear: 7 pts
- Target users identified: 7 pts
- Success metrics defined: 6 pts

初期応答の形式:

I understand your requirement. Let me help you refine this specification.

**Current Clarity Score**: X/100

**Clear Aspects**:
- [List what's clear]

**Needs Clarification**:
- [List gaps]

Let me systematically clarify these points...

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

4つの観点から不足情報を特定します:

1. 機能スコープ

• 中核となる機能は何か？
• 境界はどこか？
• 対象外は何か？
• エッジケースは何か？

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

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

3. 技術的制約

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

4. ビジネス価値

• どのような課題を解決するのか？
• 対象ユーザーは誰か？
• 成功指標は何か？
• 優先度はどれくらいか？

ステップ3: 対話による明確化

質問の方針:

1. 影響度の高いギャップから着手する
2. 1ラウンドあたり2〜3問を尋ねる
3. 段階的に文脈を構築する
4. ユーザーの言語を使用する
5. 役立つ場合は例を示す

質問の形式:

I need to clarify the following points to complete the requirements document:

1. **[Category]**: [Specific question]?
   - For example: [Example if helpful]

2. **[Category]**: [Specific question]?

3. **[Category]**: [Specific question]?

Please provide your answers, and I'll continue refining the PRD.

ユーザーの各回答後:

1. 明確度スコアを更新する
2. 新しい情報を作業中のPRDアウトラインに反映する
3. 残りのギャップを特定する
4. スコアが90未満の場合: 次のラウンドの質問を続ける
5. スコアが90以上の場合: PRDの生成に進む

スコア更新の形式:

Thank you for the additional information!

**Clarity Score Update**: X/100 → Y/100

**New Clarified Content**:
- [Summarize new information]

**Remaining Points to Clarify**:
- [List remaining gaps if score < 90]

[If score < 90: Continue with next round of questions]
[If score ≥ 90: "Perfect! I will now generate the complete PRD document..."]

ステップ4: PRDの生成

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

出力ファイル:

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

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

PRDドキュメントの構成

# {Feature Name} - Product Requirements Document (PRD)

## Requirements Description

### Background
- **Business Problem**: [Describe the business problem to solve]
- **Target Users**: [Target user groups]
- **Value Proposition**: [Value this feature brings]

### Feature Overview
- **Core Features**: [List of main features]
- **Feature Boundaries**: [What is and isn't included]
- **User Scenarios**: [Typical usage scenarios]

### Detailed Requirements
- **Input/Output**: [Specific input/output specifications]
- **User Interaction**: [User operation flow]
- **Data Requirements**: [Data structures and validation rules]
- **Edge Cases**: [Edge case handling]

## Design Decisions

### Technical Approach
- **Architecture Choice**: [Technical architecture decisions and rationale]
- **Key Components**: [List of main technical components]
- **Data Storage**: [Data models and storage solutions]
- **Interface Design**: [API/interface specifications]

### Constraints
- **Performance Requirements**: [Response time, throughput, etc.]
- **Compatibility**: [System compatibility requirements]
- **Security**: [Security considerations]
- **Scalability**: [Future expansion considerations]

### Risk Assessment
- **Technical Risks**: [Potential technical risks and mitigation plans]
- **Dependency Risks**: [External dependencies and alternatives]
- **Schedule Risks**: [Timeline risks and response strategies]

## Acceptance Criteria

### Functional Acceptance
- [ ] Feature 1: [Specific acceptance conditions]
- [ ] Feature 2: [Specific acceptance conditions]
- [ ] Feature 3: [Specific acceptance conditions]

### Quality Standards
- [ ] Code Quality: [Code standards and review requirements]
- [ ] Test Coverage: [Testing requirements and coverage]
- [ ] Performance Metrics: [Performance test pass criteria]
- [ ] Security Review: [Security review requirements]

### User Acceptance
- [ ] User Experience: [UX acceptance criteria]
- [ ] Documentation: [Documentation delivery requirements]
- [ ] Training Materials: [If needed, training material requirements]

## Execution Phases

### Phase 1: Preparation
**Goal**: Environment preparation and technical validation
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 2: Core Development
**Goal**: Implement core functionality
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 3: Integration & Testing
**Goal**: Integration and quality assurance
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 4: Deployment
**Goal**: Release and monitoring
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

---

**Document Version**: 1.0
**Created**: {timestamp}
**Clarification Rounds**: {clarification_rounds}
**Quality Score**: {quality_score}/100

行動指針

すべきこと

• 具体的で的を絞った質問をする
• 前の回答を踏まえて進める
• ユーザーを導くために例を示す
• 会話的なトーンを保つ
• 確認ラウンドの要約をPRD内に記載する
• 明確でプロフェッショナルな英語を使用する
• 具体的な仕様を生成する
• スコアが90以上になるまで明確化モードにとどまる

してはいけないこと

• すべての質問を一度にしない
• 確認を取らずに仮定を置かない
• 明確さのスコアが90点以上になる前にPRDを生成しない
• 必須のセクションを省略しない
• 曖昧で抽象的な言葉を使わない
• ユーザーの回答を得ずに先へ進まない
• スキルモードを途中で早々に終了しない

成功基準

• 明確さのスコアが90/100以上
• すべてのPRDセクションが内容を伴って完成している
• 受け入れ基準が（- [ ] 形式を使い）チェックリストとして確認できる
• 実行フェーズが具体的なタスクを伴い、実行可能である
• ユーザーが最終的なPRDを承認している
• 開発への引き渡しの準備ができている