Claude-skill-registry iterative-review

.opencode/配下のドキュメント・設定を修正する際の品質保証プロセス(修正→レビュー→修正の反復ループ)

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/iterative-review" ~/.claude/skills/majiayu000-claude-skill-registry-iterative-review && rm -rf "$T"
manifest: skills/data/iterative-review/SKILL.md
source content

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自己改善ワークフロー"""
    
    # 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全体概要