| 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 レビュー結果出力形式
## レビュー結果
### 発見した問題
| 重要度 | 場所 | 問題 | 修正案 |
|--------|------|------|--------|
| 🔴 高 | `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への指示
def opencode_self_improvement(request):
"""OpenCode自己改善ワークフロー"""
create_todo_list(request)
for todo in todos:
implement_change(todo)
mark_completed(todo)
max_iterations = 5
for i in range(max_iterations):
issues = full_review(
aspects=["consistency", "completeness", "correctness", "integration"]
)
if not issues:
break
for issue in issues:
fix_issue(issue)
if not issues:
git_add_and_commit()
else:
escalate_to_user("5回の反復後も問題が残っています。修正方針を見直してください。")
関連ドキュメント
