---
name: iterative-review
description: .opencode/配下のドキュメント・設定を修正する際の品質保証プロセス（修正→レビュー→修正の反復ループ）
---

# OpenCode自己改善ワークフロー（反復レビュー）

`.opencode/` 配下のドキュメント・設定を修正する際の品質保証プロセス。
修正→レビュー→修正を繰り返し、問題がなくなるまで継続する。

---

## 適用範囲

| 対象 | 例 |
|------|-----|
| コマンド定義 | `.opencode/command/*.md` |
| スキル定義 | `.opencode/skill/*.md` |
| エージェント定義 | `.opencode/agent/*.md` |
| 設定ファイル | `.opencode/*.json`, `.opencode/*.yml` |
| README | `.opencode/README.md` |

---

## ワークフロー概要

```
[修正依頼] 
    ↓
[Phase 1] 修正実施
    ↓
[Phase 2] 全体レビュー
    ↓
    ├── 問題あり → [Phase 3] 修正 → Phase 2 に戻る
    │
    └── 問題なし → [Phase 4] コミット
```

---

## Phase 1: 修正実施

### 1.1 変更計画

修正前にTodoリストを作成し、変更スコープを明確化する。

```
□ 変更対象ファイルの特定
□ 影響範囲の確認（他ファイルとの整合性）
□ 変更内容の具体化
```

### 1.2 修正作業

- 1ファイルずつ修正し、都度Todoを更新
- 関連ファイルの整合性を意識
- 新規ファイル追加時はgit追跡対象か確認

---

## Phase 2: 全体レビュー

修正完了後、以下の観点で全体をレビューする。

### 2.1 レビュー観点

| 観点 | チェック内容 |
|------|-------------|
| **整合性 (Consistency)** | 用語・形式・命名規則が統一されているか |
| **完全性 (Completeness)** | 必要な情報が全て記載されているか、抜け漏れはないか |
| **正確性 (Correctness)** | 論理的に正しいか、矛盾がないか |
| **統合性 (Integration)** | 他ドキュメントとの連携が正しいか |

### 2.2 整合性チェック項目

```
【形式】
□ 見出しレベルが統一されているか（### Phase X 等）
□ テーブル形式が統一されているか
□ コードブロックの言語指定が適切か

【用語】
□ 同じ概念に同じ用語を使用しているか
□ 略称と正式名称の使い分けが一貫しているか

【スキーマ・データ】
□ JSONスキーマとドキュメント例が一致しているか
□ 列挙値（enum）が全箇所で一致しているか
□ 必須/任意フィールドの記載が正確か
```

### 2.3 完全性チェック項目

```
【ドキュメント構造】
□ 冒頭の概要説明がフェーズ構成と一致しているか
□ 全フェーズが説明されているか
□ 疑似コードがある場合、本文と一致しているか

【関連定義】
□ 参照される関数/ツールが定義されているか
□ エラーハンドリングが網羅されているか
□ エッジケースが考慮されているか
```

### 2.4 正確性チェック項目

```
【論理整合性】
□ フェーズ番号が順序通りか（0, 0.5, 1, 2, 2.5, 3...）
□ 条件分岐が矛盾していないか
□ 前提条件と実行内容が整合しているか

【技術的正確性】
□ ツール名・関数名が正確か
□ ファイルパスが正確か
□ 設定値が有効か
```

### 2.5 統合性チェック項目

```
【クロスリファレンス】
□ 参照先ドキュメントが存在するか
□ 参照元と参照先で情報が一致しているか
□ バージョン/変更履歴が更新されているか

【ワークフロー連携】
□ 前工程・後工程との接続が正しいか
□ 共有データ形式が一致しているか
```

### 2.6 レビュー結果出力形式

```markdown
## レビュー結果

### 発見した問題

| 重要度 | 場所 | 問題 | 修正案 |
|--------|------|------|--------|
| 🔴 高 | `file.md` L123 | [問題の説明] | [修正方法] |
| 🟡 中 | `file.md` L456 | [問題の説明] | [修正方法] |
| 🟢 低 | `file.md` L789 | [問題の説明] | [修正方法] |

### 良好な点 ✅

| 項目 | 状態 |
|------|------|
| [チェック項目] | ✅ [状態説明] |

### 判定

- 問題あり → 修正してください
- 問題なし → コミット可能です
```

---

## Phase 3: 修正

### 3.1 優先度に基づく修正

| 重要度 | アクション |
|--------|-----------|
| 🔴 高 (Critical) | **必須修正** - 機能に影響、または重大な矛盾 |
| 🟡 中 (Major) | **修正推奨** - 整合性・完全性の問題 |
| 🟢 低 (Minor) | **任意修正** - 軽微な改善点 |

### 3.2 修正後の確認

```
□ 指摘された全ての🔴高を修正したか
□ 修正により新たな不整合が発生していないか
□ 関連ファイルも更新したか
```

### 3.3 Phase 2 へ戻る

修正完了後、再度 Phase 2（全体レビュー）を実施。
問題がなくなるまで繰り返す。

---

## Phase 4: コミット

### 4.1 コミット前チェック

```
□ 全てのレビュー指摘が解消されている
□ git status で変更ファイルを確認
□ 新規ファイルがある場合、git add 対象か確認
□ .gitignore 対象のファイルを誤ってコミットしていないか
```

### 4.2 コミットメッセージ形式

```
feat(opencode): [変更の要約]

- [変更点1]
- [変更点2]
- [変更点3]
```

---

## 反復回数の目安

| 修正規模 | 想定反復回数 |
|---------|-------------|
| 単一ファイル軽微修正 | 1-2回 |
| 複数ファイル修正 | 2-3回 |
| 新機能追加 | 3-5回 |
| 大規模リファクタリング | 5回以上 |

> **注意**: 5回を超えても問題が解消しない場合、修正方針自体を見直すこと。

---

## アンチパターン

| ❌ やってはいけない | ✅ 正しい方法 |
|-------------------|-------------|
| レビューなしでコミット | 必ず全体レビューを実施 |
| 🔴高を残したままコミット | 全ての🔴高を解消してからコミット |
| 修正のたびに部分レビュー | 修正後は必ず**全体**レビュー |
| 問題を先送り（TODO化） | その場で修正を完了 |
| レビュー観点の省略 | 4観点（整合性/完全性/正確性/統合性）全てを確認 |

---

## 使用例

### ユーザーからの依頼

```
ユーザー: 承認ゲートをワークフローに追加して
```

### Sisyphusの対応

```
1. [Phase 1] 修正実施
   - req-workflow.md に承認ゲート追加
   - basic-design-workflow.md に承認ゲート追加
   - detailed-design-workflow.md に承認ゲート追加

2. [Phase 2] 全体レビュー
   → 問題発見: Phase見出しが不統一（##と###混在）

3. [Phase 3] 修正
   - 見出しを### に統一

4. [Phase 2] 再レビュー
   → 問題発見: 疑似コードに承認ゲートが反映されていない

5. [Phase 3] 修正
   - 疑似コードを更新

6. [Phase 2] 再レビュー
   → 問題なし ✅

7. [Phase 4] コミット
```

---

## Sisyphusへの指示

```python
def opencode_self_improvement(request):
    """OpenCode自己改善ワークフロー"""
    
    # Phase 1: 修正実施
    create_todo_list(request)
    for todo in todos:
        implement_change(todo)
        mark_completed(todo)
    
    # Phase 2-3: レビュー・修正ループ
    max_iterations = 5
    for i in range(max_iterations):
        # Phase 2: 全体レビュー
        issues = full_review(
            aspects=["consistency", "completeness", "correctness", "integration"]
        )
        
        if not issues:
            break  # 問題なし → Phase 4へ
        
        # Phase 3: 修正
        for issue in issues:
            fix_issue(issue)
        
        # 再度 Phase 2 へ
    
    # Phase 4: コミット
    if not issues:
        git_add_and_commit()
    else:
        escalate_to_user("5回の反復後も問題が残っています。修正方針を見直してください。")
```

---

## 関連ドキュメント

- [README](./../README.md) - OpenCode全体概要