Iterative Review

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

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

適用範囲

ワークフロー概要

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

Phase 1: 修正実施

1.1 変更計画

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

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

1.2 修正作業

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

Phase 2: 全体レビュー

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

2.1 レビュー観点

2.2 整合性チェック項目

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

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

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

2.3 完全性チェック項目

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

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

2.4 正確性チェック項目

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

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

2.5 統合性チェック項目

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

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

2.6 レビュー結果出力形式

## レビュー結果

### 発見した問題

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

### 良好な点 ✅

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

### 判定

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

Phase 3: 修正

3.1 優先度に基づく修正

3.2 修正後の確認

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

3.3 Phase 2 へ戻る

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

Phase 4: コミット

4.1 コミット前チェック

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

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

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

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

反復回数の目安

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

アンチパターン

使用例

ユーザーからの依頼

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

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への指示

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 - OpenCode全体概要
• container-use-guide - コンテナ環境ガイド