仕様レビュー・実装検討スキル

Geminiなどから取得した情報を鵜呑みにせず、現状のシステムと照らし合わせて妥当性を検証し、実装方針を決定します。

使用タイミング

•/save-spec で仕様書を保存した後
•新機能の実装検討時
•外部情報に基づく改修検討時
•/review-spec コマンド実行時

実行フロー

code

┌─────────────────────────────────────────────────────────────┐
│ Phase 1: 情報収集                                           │
│ ├── 新仕様書の読み込み (specs/)                             │
│ ├── 関連する現行仕様の特定                                  │
│ └── 関連コードの調査                                        │
├─────────────────────────────────────────────────────────────┤
│ Phase 2: 比較分析                                           │
│ ├── 差分抽出                                                │
│ ├── 互換性チェック                                          │
│ └── 影響範囲特定                                            │
├─────────────────────────────────────────────────────────────┤
│ Phase 3: 影響度判定                                         │
│ ├── 変更カテゴリ分類                                        │
│ ├── リスク評価                                              │
│ └── 工数見積もり（相対）                                    │
├─────────────────────────────────────────────────────────────┤
│ Phase 4: ユーザー確認                                       │
│ ├── レポート提示                                            │
│ ├── 選択肢提示                                              │
│ └── 決定待ち                                                │
├─────────────────────────────────────────────────────────────┤
│ Phase 5: 仕様確定・実装開始                                 │
│ ├── docs/仕様書更新                                         │
│ ├── 実装計画作成                                            │
│ └── TDDワークフロー開始                                     │
└─────────────────────────────────────────────────────────────┘

Phase 1: 情報収集

1.1 新仕様書の読み込み

python

# 対象ファイルの特定
target_spec = "specs/phases/PHASE{N}_{TOPIC}.md"
# または
target_spec = "specs/api/API_{SERVICE}.md"

1.2 関連する現行仕様の特定

以下のディレクトリを調査:

場所	内容
`duo-talk-core/docs/`	コアシステム仕様
`duo-talk-director/docs/`	Director仕様
`duo-talk-evaluation/specs/`	評価・実験仕様
`duo-talk-*/src/`	実装コード

1.3 関連コードの調査

bash

# 関連ファイルの検索
grep -r "{キーワード}" --include="*.py" duo-talk-*/src/

Phase 2: 比較分析

2.1 差分抽出テンプレート

markdown

## 差分分析

### 新仕様の主張
- {Geminiからの情報のポイント1}
- {Geminiからの情報のポイント2}

### 現行仕様
- {現在の実装/仕様のポイント1}
- {現在の実装/仕様のポイント2}

### 差分
| 項目 | 新仕様 | 現行 | 差分タイプ |
|------|--------|------|-----------|
| {項目1} | {新} | {現} | 追加/変更/削除 |
| {項目2} | {新} | {現} | 追加/変更/削除 |

2.2 互換性チェック

markdown

## 互換性チェック

### API互換性
- [ ] 既存APIシグネチャの変更が必要か
- [ ] 戻り値の型変更が必要か
- [ ] 新規APIの追加のみか

### データ互換性
- [ ] 既存データ構造の変更が必要か
- [ ] マイグレーションが必要か
- [ ] 新規フィールド追加のみか

### 依存関係
- [ ] 新規ライブラリが必要か
- [ ] 既存ライブラリのバージョン更新が必要か
- [ ] 依存関係の競合はないか

2.3 影響範囲特定

markdown

## 影響範囲

### 直接影響
- {ファイル1}: {変更内容}
- {ファイル2}: {変更内容}

### 間接影響
- {ファイル3}: {テスト更新が必要}
- {ファイル4}: {ドキュメント更新が必要}

### 影響を受けるテスト
- tests/test_{module}.py

Phase 3: 影響度判定

3.1 変更カテゴリ分類

カテゴリ	定義	例
A: 追加	既存に影響なし、新規追加のみ	新Checker追加、新シナリオ追加
B: 軽微な修正	1-3ファイル、API互換性維持	バグ修正、パラメータ追加
C: 大規模改造	4+ファイル、リファクタリング必要	アーキテクチャ変更、新機能追加
D: システム変更	基盤変更、全体影響	フレームワーク変更、DB変更

3.2 判定基準

code

影響ファイル数:
  1-3件 → A or B
  4-10件 → B or C
  10+件 → C or D

API変更:
  なし → A or B
  後方互換 → B or C
  破壊的変更 → C or D

テスト影響:
  なし → A
  一部 → B or C
  全体 → C or D

3.3 リスク評価

markdown

## リスク評価

| リスク項目 | レベル | 説明 |
|-----------|--------|------|
| 実装リスク | 低/中/高 | {理由} |
| テストリスク | 低/中/高 | {理由} |
| 運用リスク | 低/中/高 | {理由} |
| ロールバックリスク | 低/中/高 | {理由} |

Phase 4: ユーザー確認

4.1 レポート出力フォーマット

markdown

# 仕様レビューレポート

## 概要
- **対象仕様**: {specs/phases/PHASE2_XXX.md}
- **情報源**: Gemini / Web検索 / その他
- **判定結果**: **{A/B/C/D}: {カテゴリ名}**

---

## 差分サマリー

| 項目 | 新仕様 | 現行 | 影響 |
|------|--------|------|------|
| ... | ... | ... | ... |

---

## 影響範囲

### 変更が必要なファイル
1. `duo-talk-{repo}/src/{file}.py` - {変更内容}
2. ...

### テスト影響
- {N}件のテストに影響

---

## リスク評価

| 項目 | レベル |
|------|--------|
| 実装リスク | {低/中/高} |
| テストリスク | {低/中/高} |

---

## Gemini情報の妥当性検証

### ✅ 妥当と判断
- {理由1}
- {理由2}

### ⚠️ 要検証/修正
- {問題点1}: {修正案}
- {問題点2}: {修正案}

### ❌ 不採用/却下
- {理由}（該当する場合のみ）

---

## 選択肢

1. **採用して実装開始** - 仕様を確定し、TDDで実装
2. **修正して採用** - 指摘事項を修正後に採用
3. **追加調査** - 不明点を追加調査
4. **保留** - 優先度を下げて保留
5. **却下** - 採用しない

4.2 ユーザーへの質問

code

AskUserQuestion を使用:

質問: この仕様をどう進めますか？

選択肢:
1. 採用して実装開始（推奨）
2. 修正して採用
3. 追加調査
4. 保留
5. 却下

Phase 5: 仕様確定・実装開始

5.1 仕様書の確定

ユーザーが「採用」を選択した場合:

•

specs/ → docs/ への移行

code

specs/phases/PHASE2_DIRECTOR_LLM.md
↓
duo-talk-director/docs/PHASE2_DIRECTOR_LLM.md

•

ステータス更新

markdown

**ステータス**: Draft → Approved
**承認日**: {今日の日付}

5.2 実装計画の作成

markdown

# 実装計画: {機能名}

## フェーズ分割

### Phase 1: インターフェース定義
- [ ] 型定義の追加
- [ ] Protocolの定義

### Phase 2: テスト作成（TDD RED）
- [ ] ユニットテスト
- [ ] 統合テスト

### Phase 3: 実装（TDD GREEN）
- [ ] コア機能実装
- [ ] エラーハンドリング

### Phase 4: リファクタリング（TDD REFACTOR）
- [ ] コード整理
- [ ] ドキュメント更新

## ファイル一覧
| ファイル | 変更タイプ | 優先度 |
|----------|-----------|--------|
| ... | 新規/変更 | 高/中/低 |

5.3 TDDワークフロー開始

everything-claude-codeの作法に従い:

•/tdd スキルを呼び出し
•テスト先行で実装
•80%以上のカバレッジを維持
•/code-reviewで品質確認

出力例

code

============================================================
仕様レビュー完了
============================================================

📄 対象: specs/phases/PHASE2_DIRECTOR_LLM.md
🏷️ 判定: **B: 軽微な修正**

## 差分サマリー
- LLMEvaluator に新メソッド追加
- ThresholdConfig にパラメータ追加
- 既存APIは互換性維持

## 影響範囲
- 変更ファイル: 3件
- テスト影響: 5件

## Gemini情報の妥当性
✅ 妥当: API設計は現行アーキテクチャと整合
⚠️ 要検証: 閾値の具体値は実験で検証必要

## 次のアクション
→ ユーザー確認待ち

[1] 採用して実装開始（推奨）
[2] 修正して採用
[3] 追加調査
[4] 保留
[5] 却下

注意事項

•
Gemini情報を鵜呑みにしない
- •必ず現行コードと照合
- •矛盾があれば指摘
•
影響範囲は保守的に見積もる
- •隠れた依存関係に注意
- •テストカバレッジを確認
•
ユーザー判断を尊重
- •推奨は示すが強制しない
- •却下の判断も尊重
•
everything-claude-code準拠
- •TDDワークフロー
- •code-review必須
- •security-review（必要時）