# kairo-requirements

## 目的

ユーザから提供された要件の概要を分析し、EARS（Easy Approach to Requirements Syntax）記法を使用して詳細な受け入れ基準を含む要件定義書を作成する。

## 前提条件

- ユーザから要件の概要が提供されている
- `docs/spec/` ディレクトリが存在する（なければ作成）

## 実行内容

1. **要件の分析**
   - ユーザから提供された要件の概要を理解する
   - 関連するドメイン知識を適用する
   - 不明確な点がある場合は、一般的なベストプラクティスに基づいて補完する

2. **ユーザストーリーの作成**
   - WHO（誰が）、WHAT（何を）、WHY（なぜ）の形式で記述
   - 各機能の価値を明確にする

3. **EARS記法による要件定義**
   - **通常要件（SHALL）**: システムが通常実行すべき動作
   - **条件付き要件（WHEN/IF-THEN）**: 特定の条件下での動作
   - **不要要件（WHERE）**: 特定の状態での動作
   - **オプション要件（MAY）**: 任意の機能
   - **制約要件（MUST）**: システムの制約事項

4. **Edgeケースの定義**
   - 異常系の処理
   - 境界値の処理
   - エラーハンドリング
   - パフォーマンス要件

5. **ファイルの作成**
   - `docs/spec/{要件名}-requirements.md` として保存
   - マークダウン形式で構造化された文書を作成

## 出力フォーマット例

```markdown
# {要件名} 要件定義書

## 概要

{要件の概要}

## ユーザストーリー

### ストーリー1: {タイトル}

- **である** {ユーザー種別} **として**
- **私は** {実現したいこと} **をしたい**
- **そうすることで** {得られる価値}

## 機能要件（EARS記法）

### 通常要件

- REQ-001: システムは {通常の動作} しなければならない
- REQ-002: システムは {通常の動作} しなければならない

### 条件付き要件

- REQ-101: {条件} の場合、システムは {動作} しなければならない
- REQ-102: {条件} の場合、システムは {動作} しなければならない

### 状態要件

- REQ-201: {状態} にある場合、システムは {動作} しなければならない

### オプション要件

- REQ-301: システムは {オプション機能} してもよい

### 制約要件

- REQ-401: システムは {制約事項} しなければならない

## 非機能要件

### パフォーマンス

- NFR-001: {パフォーマンス要件}

### セキュリティ

- NFR-101: {セキュリティ要件}

### ユーザビリティ

- NFR-201: {ユーザビリティ要件}

## Edgeケース

### エラー処理

- EDGE-001: {エラーケース}

### 境界値

- EDGE-101: {境界値ケース}

## 受け入れ基準

### 機能テスト

- [ ] {テスト項目}

### 非機能テスト

- [ ] {テスト項目}
```

## 実行後の確認

- 作成したファイルのパスを表示
- 主要な要件の数を報告
- ユーザに確認を促すメッセージを表示