Menu
.opencode/配下のドキュメント・設定を修正する際の品質保証プロセス（修正→レビュー→修正の反復ループ）
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
PR作成後のCI監視、失敗時の分類と対応、自動マージまでの完全なワークフローを定義
GitHub Issue間の依存関係（Is blocking / Blocked by）を設定・取得するためのAPI操作を提供
GitHub Issueのラベルとメタデータを使用した環境状態管理。worktree/ホスト環境すべてからアクセス可能なSingle Source of Truth
PRの作成からマージ、クリーンアップ、ロールバックまでの標準フローを定義
バージョン整合性チェック→提案→承認→GitHub Release作成までの標準リリースフロー（マルチエコシステム対応）
Git worktree を作成し、並行開発用の独立したブランチ環境を構築する。プラットフォーム固有コード開発時に使用。
| name | iterative-review |
| description | .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] コミット
修正前にTodoリストを作成し、変更スコープを明確化する。
□ 変更対象ファイルの特定
□ 影響範囲の確認（他ファイルとの整合性）
□ 変更内容の具体化
修正完了後、以下の観点で全体をレビューする。
| 観点 | チェック内容 |
|---|---|
| 整合性 (Consistency) | 用語・形式・命名規則が統一されているか |
| 完全性 (Completeness) | 必要な情報が全て記載されているか、抜け漏れはないか |
| 正確性 (Correctness) | 論理的に正しいか、矛盾がないか |
| 統合性 (Integration) | 他ドキュメントとの連携が正しいか |
【形式】
□ 見出しレベルが統一されているか（### Phase X 等）
□ テーブル形式が統一されているか
□ コードブロックの言語指定が適切か
【用語】
□ 同じ概念に同じ用語を使用しているか
□ 略称と正式名称の使い分けが一貫しているか
【スキーマ・データ】
□ JSONスキーマとドキュメント例が一致しているか
□ 列挙値（enum）が全箇所で一致しているか
□ 必須/任意フィールドの記載が正確か
【ドキュメント構造】
□ 冒頭の概要説明がフェーズ構成と一致しているか
□ 全フェーズが説明されているか
□ 疑似コードがある場合、本文と一致しているか
【関連定義】
□ 参照される関数/ツールが定義されているか
□ エラーハンドリングが網羅されているか
□ エッジケースが考慮されているか
【論理整合性】
□ フェーズ番号が順序通りか（0, 0.5, 1, 2, 2.5, 3...）
□ 条件分岐が矛盾していないか
□ 前提条件と実行内容が整合しているか
【技術的正確性】
□ ツール名・関数名が正確か
□ ファイルパスが正確か
□ 設定値が有効か
【クロスリファレンス】
□ 参照先ドキュメントが存在するか
□ 参照元と参照先で情報が一致しているか
□ バージョン/変更履歴が更新されているか
【ワークフロー連携】
□ 前工程・後工程との接続が正しいか
□ 共有データ形式が一致しているか
## レビュー結果
### 発見した問題
| 重要度 | 場所 | 問題 | 修正案 |
|--------|------|------|--------|
| 🔴 高 | `file.md` L123 | [問題の説明] | [修正方法] |
| 🟡 中 | `file.md` L456 | [問題の説明] | [修正方法] |
| 🟢 低 | `file.md` L789 | [問題の説明] | [修正方法] |
### 良好な点 ✅
| 項目 | 状態 |
|------|------|
| [チェック項目] | ✅ [状態説明] |
### 判定
- 問題あり → 修正してください
- 問題なし → コミット可能です
| 重要度 | アクション |
|---|---|
| 🔴 高 (Critical) | 必須修正 - 機能に影響、または重大な矛盾 |
| 🟡 中 (Major) | 修正推奨 - 整合性・完全性の問題 |
| 🟢 低 (Minor) | 任意修正 - 軽微な改善点 |
□ 指摘された全ての🔴高を修正したか
□ 修正により新たな不整合が発生していないか
□ 関連ファイルも更新したか
修正完了後、再度 Phase 2（全体レビュー）を実施。 問題がなくなるまで繰り返す。
□ 全てのレビュー指摘が解消されている
□ git status で変更ファイルを確認
□ 新規ファイルがある場合、git add 対象か確認
□ .gitignore 対象のファイルを誤ってコミットしていないか
feat(opencode): [変更の要約]
- [変更点1]
- [変更点2]
- [変更点3]
| 修正規模 | 想定反復回数 |
|---|---|
| 単一ファイル軽微修正 | 1-2回 |
| 複数ファイル修正 | 2-3回 |
| 新機能追加 | 3-5回 |
| 大規模リファクタリング | 5回以上 |
注意: 5回を超えても問題が解消しない場合、修正方針自体を見直すこと。
| ❌ やってはいけない | ✅ 正しい方法 |
|---|---|
| レビューなしでコミット | 必ず全体レビューを実施 |
| 🔴高を残したままコミット | 全ての🔴高を解消してからコミット |
| 修正のたびに部分レビュー | 修正後は必ず全体レビュー |
| 問題を先送り（TODO化） | その場で修正を完了 |
| レビュー観点の省略 | 4観点（整合性/完全性/正確性/統合性）全てを確認 |
ユーザー: 承認ゲートをワークフローに追加して
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] コミット
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回の反復後も問題が残っています。修正方針を見直してください。")