القائمة
PR作成前の品質レビュー実行フロー、客観的品質基準、同一指摘検出、エスカレーション手順を定義
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
PR作成後のCI監視、失敗時の分類と対応、自動マージまでの完全なワークフローを定義
GitHub Issue間の依存関係（Is blocking / Blocked by）を設定・取得するためのAPI操作を提供
GitHub Issueのラベルとメタデータを使用した環境状態管理。worktree/ホスト環境すべてからアクセス可能なSingle Source of Truth
PRの作成からマージ、クリーンアップ、ロールバックまでの標準フローを定義
バージョン整合性チェック→提案→承認→GitHub Release作成までの標準リリースフロー（マルチエコシステム対応）
Git worktree を作成し、並行開発用の独立したブランチ環境を構築する。プラットフォーム固有コード開発時に使用。
| name | quality-review-flow |
| description | PR作成前の品質レビュー実行フロー、客観的品質基準、同一指摘検出、エスカレーション手順を定義 |
参照元: 実装ワークフローから分離された品質レビューロジック
⚠️ 重要: PR作成前に必ず品質レビューを実行。スキップ厳禁。
| 実装内容 | エージェント |
|---|---|
| バックエンド/CLI | backend-reviewer |
| フロントエンド | frontend-reviewer |
| DB関連 | database-reviewer |
| インフラ | infra-reviewer |
| セキュリティ | security-reviewer |
⚠️ 重要: レビュアーエージェントは、ファイル全体ではなく変更差分を中心にレビューすること。
git diff main...HEAD で変更箇所のみを取得# レビューエージェントへの指示例
prompt = """
レビュー対象:
1. `git diff main...HEAD` の出力（変更点）
2. 変更されたファイルの関連箇所（全体ではない）
確認事項:
- 変更が要件を満たしているか
- 既存機能を破壊していないか
"""
参照: 閾値の正式定義は
workflow-phase-conventionskill §レビュースコア閾値を参照
| スコア | アクション |
|---|---|
| 9-10点 | ✅ PR作成へ |
| 7-8点 | 修正 → 再レビュー |
| 6点以下 | 設計見直し |
このセクションが客観的品質基準の唯一の定義（Single Source of Truth）です。 他ファイルからはこのセクションを参照してください。
レビュースコアに加え、以下の客観的基準を満たす必要があります。 これらはAIの主観に依存せず、ツールで検証可能です。
| 基準 | 検証コマンド（Rust） | 検証コマンド（TypeScript） | 必須 |
|---|---|---|---|
| Lintエラー 0件 | cargo clippy -- -D warnings | npm run lint | ✅ |
| 型エラー 0件 | cargo check | npm run type-check | ✅ |
| フォーマット準拠 | cargo fmt --check | npm run format:check | ✅ |
| テスト全通過 | cargo test | npm test | ✅ |
| カバレッジ 80%以上 | cargo tarpaulin | npm run coverage | 推奨 |
実装したコードがエントリポイントから呼び出されることを確認する。
| プロジェクト種別 | エントリポイント | 確認コマンド例 |
|---|---|---|
| Rust CLI | src/main.rs | grep -E 'handler_name|mod handler' src/main.rs |
| Next.js App Router | app/**/page.tsx | 実装コンポーネントの import 確認 |
| Next.js Pages Router | pages/**/*.tsx | 実装コンポーネントの import 確認 |
| Express/Fastify | src/app.ts or src/index.ts | route/controller 参照確認 |
| Spring Boot | *Application.java | Bean/Component 参照確認 |
アクション:
定義された引数/Props/パラメータが実際に使用されているかを確認する。
| プロジェクト種別 | 定義元 | 使用先 | 確認コマンド例 |
|---|---|---|---|
| Rust CLI | args.rs (struct fields) | handlers.rs | grep 'args\.field_name' src/ |
| Python CLI | argparse.add_argument() | handler関数 | 引数変数の使用確認 |
| REST API | OpenAPI spec / DTO | Controller | パラメータ使用確認 |
| React/Vue | Props 定義 | Component 本体 | props 参照確認 |
アクション:
| 条件 | 結果 |
|---|---|
| 全基準クリア | PR作成可 |
| ツール検証失敗（Lint/型/テスト） | 修正必須、PR作成不可 |
| 到達可能性NG | 統合必須、PR作成不可 |
| 定義-使用相関NG（スタブあり） | -2点減点、軽微なら警告付きで続行可 |
Note: 客観的基準が未達の場合、レビュースコアに関係なく PR 作成不可。
重要: Phase 6.6 で実行。設計書で定義された全機能が実装・統合されていることを確認する。 このチェックをスキップすると、機能が作成されても使われない「死にコード」が発生するリスクあり。
| チェック項目 | 確認方法 | 失敗時アクション |
|---|---|---|
| 全機能実装 | 設計書「実装内容」の全項目を確認 | 未実装→Phase 5に戻る |
| 呼び出し元統合 | 設計書「呼び出し元」の全ポイントを確認 | 統合漏れ→Phase 5に戻る |
| CLIコマンド動作 | 設計書定義のCLIが動作するか | 動作NG→Phase 5に戻る |
| E2E動作 | 主要フローがE2Eで動作するか | 動作NG→Phase 5に戻る |
# 1. 実装内容の存在確認
grep -r '{ClassName}\|{FunctionName}' src/
# 2. 呼び出し元からの参照確認
grep -r 'import.*{ModuleName}\|use.*{ModuleName}' {caller_path}
# 3. CLIコマンド動作確認（該当する場合）
{cli_binary} {command} --help
{cli_binary} {command} {test_args}
# 4. E2E動作確認
npm run dev # または cargo run
# → 手動で主要フローを確認、または自動E2Eテスト実行
| 状況 | アクション |
|---|---|
| セクションなし（古い設計書） | 実装者が統合ポイントを特定し、設計書に追記 |
| 統合ポイントが不明確 | /request-design-fix で設計書更新を依頼 |
| 条件 | 結果 |
|---|---|
| 全機能実装 + 全統合確認 + CLI動作OK + E2E動作OK | ✅ Phase 7 へ |
| 未実装あり | ❌ Phase 5 に戻って実装 |
| 統合漏れあり | ❌ Phase 5 に戻って統合コード追加 |
| CLI/E2E動作NG | ❌ Phase 5 に戻って修正 |
Note: このチェックを通過しないと品質レビュー（Phase 7）に進めません。
同じ指摘が繰り返される場合は即座にエスカレーションします。
| 条件 | アクション |
|---|---|
| 前回指摘と50%以上重複 | 即座にエスカレーション |
| 3回連続で9点未満 | Blocked状態へ移行 |
レビュー実行 → スコア9点以上? → Yes → PR作成へ
↓ No
同一指摘50%以上? → Yes → エスカレーション
↓ No
リトライ回数 < 3? → Yes → 修正 → 再レビュー
↓ No
Blocked状態へ移行
Token最適化: レビュー指摘をTODOファイルに保存し、再実装時はTODOのみ参照。 設計書・既存コードの再読み込みを最小限に抑える。
レビュー指摘事項を構造化TODOファイルに保存：
保存先: .review-todo/issue-{subtask_id}-attempt-{attempt}.md
TODOファイル形式:
# Review TODO: Issue #42
## Review Score: 7/10
## Attempt: 1/3
### 指摘事項（優先度順）
- [ ] **HIGH**: エラーハンドリング不足 (File: handlers.rs, Line: 45)
- [ ] **MEDIUM**: 命名規則違反 (File: args.rs, Line: 12)
### 修正ガイド
| 指摘 | 修正方針 | 参照セクション |
|------|---------|--------------|
| エラーハンドリング... | Result型でラップ | ## エラー処理 |
| 命名規則違反... | snake_caseに修正 | N/A |
### ⚠️ 再実装時の注意
- このTODOファイルのみ参照して修正
- 設計書の再読み込みは「参照セクション」が指定された場合のみ
📋 レビュー完了（スコア < 9）
↓
💾 TODOファイル生成 (.review-todo/issue-N-attempt-M.md)
↓
🔧 再実装（TODOファイルのみ参照）
├─ 指摘事項を上から順に修正
├─ 修正完了したらチェック☑
└─ 「参照セクション」がある場合のみ設計書をピンポイント読み込み
↓
🧪 テスト再実行
↓
📝 再レビュー依頼（修正サマリ付き）
再レビュー時は以下の情報のみを渡す（トークン最適化）：
| 渡す情報 | 内容 |
|---|---|
| 前回スコア | 7/10 など |
| 修正TODOファイル | .review-todo/issue-N-attempt-M.md の内容 |
| 修正サマリ | 何を修正したかの簡潔な説明 |
禁止: 設計書・コード全文の再読み込み
Note: 以下は設計書全文（2,000-5,000トークン）をTODOファイル（300-500トークン）に置き換えた場合の推定値です。 実際の削減率はプロジェクトの設計書サイズやレビュー指摘数に依存します。
| フェーズ | 従来方式 | TODO駆動方式 | 推定削減率 |
|---|---|---|---|
| 1回目レビュー後 | 設計書全文 + コード全文読み込み | TODOファイルのみ | 約60-70% |
| 2回目レビュー後 | 設計書全文 + コード全文読み込み | TODOファイルのみ | 約60-70% |
| 3回目レビュー後 | 設計書全文 + コード全文読み込み | TODOファイルのみ | 約60-70% |
推定累積効果: 3回のレビューループで数千トークン節約
重要: TODOファイルは worktree またはホスト環境内に保存されるため、セッション間で永続化される。
状態管理API:
github-issue-state-managementskill を参照
| タイミング | 操作 |
|---|---|
| TODOファイル生成時 | Issue にコメントを追加（gh issue comment） |
Phaseを review-fix に更新 | issue-state.sh phase <num> 7-review |
| セッション再開時 | Issue コメントから直近の review-todo を検索 |
.review-todo/
├── issue-42-attempt-1.md # 1回目レビュー後のTODO
├── issue-42-attempt-2.md # 2回目レビュー後のTODO
├── issue-42-attempt-3.md # 3回目レビュー後のTODO（Blocked判定）
└── .gitignore # Git管理外
レビュー3回失敗時、Issue を blocked 状態に更新（github-issue-state-management skill API）：
bash .opencode/skill/github-issue-state-management/scripts/issue-state.sh block <issue-num> review_loop_exceeded "レビュー3回失敗（最終スコア: X/10）"
その後、Draft PRを作成して中断。
3回連続でスコア9点未満の場合：
env:blocked ラベルを追加、Blocked コメントを投稿--draftフラグ）