approval-gate

takemo101's avatarfrom takemo101

ワークフローの重要なフェーズ移行前にユーザーの明示的な承認を必要とする承認ゲートの共通フォーマットとパターンを定義

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 11, 2026
[Guardrails and Safety]

When & Why to Use This Skill

This Claude skill establishes a standardized 'Approval Gate' framework for AI-driven workflows, ensuring that critical transitions—such as moving from design to implementation—require explicit human authorization. By defining common formats for review summaries, quality score thresholds, and clear decision-making patterns (Continue/Modify/Abort), it implements a robust Human-in-the-Loop (HITL) mechanism that prevents autonomous errors and maintains high output standards.

Use Cases

  • Software Development Lifecycle Control: Implementing mandatory review points between requirement gathering, architectural design, and code implementation to ensure project alignment.
  • Quality Assurance Gating: Automatically halting workflows if generated documents or code fall below specific quality scores until a human provides feedback or approval.
  • Automated PR Management: Managing the transition from code completion to Pull Request creation, allowing users to approve, request changes, or opt for Draft PRs.
  • Safety-Critical Task Execution: Preventing agents from executing high-impact actions like version releases or file deletions without a documented approval trail.
nameapproval-gate
descriptionワークフローの重要なフェーズ移行前にユーザーの明示的な承認を必要とする承認ゲートの共通フォーマットとパターンを定義

承認ゲート共通フォーマット

参照元: 各ワークフロー（req-workflow, basic-design-workflow, detailed-design-workflow, implement-issues）から分離された承認ゲートパターン

概要

全てのワークフローは、重要なフェーズ移行前にユーザーの明示的な承認を必要とする。

原則: ユーザーからの明示的な応答があるまで次のフェーズに進んではならない。

承認ゲートの種類

参照: 合格基準の正式定義は {{skill:workflow-phase-convention}} §レビュースコア閾値を参照

ワークフロー フェーズ ドキュメント種別 合格基準 次のアクション
/req-workflow Phase 2.5 要件定義書 8点以上 成果物サマリー → 基本設計へ
/basic-design-workflow Phase 2.5 基本設計書 9点以上 詳細設計準備へ
/detailed-design-workflow Phase 2.5 詳細設計書群 9点以上 成果物作成へ
/implement-issues Phase 7.1 実装コード 9点以上 PR作成へ
/tech-catchup-workflow Phase 2.5 技術調査結果 - レポート作成へ
/decompose-issue Phase 3.5 Issue分解計画 - Subtask作成へ
/release Phase 2.5 バージョン提案 - リリース実行へ
/reverse-engineer Phase 3.8 設計書生成結果 8点以上 ファイル出力へ

出力フォーマット

設計ワークフロー用（共通テンプレート）

---
## 🔔 承認リクエスト: {ドキュメント種別}レビュー完了

### レビュー結果サマリー
| 項目 | 結果 |
|------|------|
| 最終スコア | X/10点 |
| レビュー回数 | Y回 |
| 合格基準 | {N}点以上 ✅ |

### 成果物
- **パス**: `{file_path}`

### 主要な内容（抜粋）
{summary_table_or_list}

### 未解決課題（あれば）
| ID | 課題 | 対応方針 |
|----|------|---------|
| I-XXX | [課題] | [方針] |

---
**次のアクション**: {next_action}

⏸️ **承認待ち**: 続行してよろしいですか？

1. 続行 → {continue_action}
2. 修正 → 指摘箇所を修正（コメントで指示してください）
3. 中断 → ワークフローを終了

> 番号を選択してください（1-3）:
---

実装ワークフロー用（PR作成承認）

## ✅ 品質レビュー通過 - PR作成承認リクエスト

### Issue情報
- **Issue**: #{issue_id} - {issue_title}
- **ブランチ**: `feature/issue-{issue_id}-{description}`

### レビュー結果
- **スコア**: {score}/10
- **レビュアー**: {reviewer_agent}

### 変更概要
- 新規ファイル: {new_files_count}件
- 変更ファイル: {modified_files_count}件
- 削除ファイル: {deleted_files_count}件

### 主な変更内容
{change_summary}

### テスト結果
- 合計: {total_tests}件
- 成功: {passed_tests}件
- 失敗: {failed_tests}件

---

**PR作成を承認しますか？**

1. 続行 → PR作成を続行
2. 修正 → 追加修正が必要（指摘箇所をコメントしてください）
3. 下書き → Draft PRとして作成

> 番号を選択してください（1-3）:

ユーザー回答と対応アクション

設計ワークフロー共通

ユーザー回答 アクション
1 次のフェーズへ進む
2 + フィードバック 指摘箇所を修正し、再レビュー
3 ワークフローを終了（成果物は保持）

実装ワークフロー（PR作成）

ユーザー回答 アクション
1 通常PRを作成
2 + フィードバック 指摘箇所を修正 → 再レビュー
3 Draft PRを作成（--draftフラグ付き）
タイムアウト（30分） Draft PRを自動作成、ユーザーに通知

タイムアウト仕様（実装ワークフローのみ）

パラメータ 値 説明
タイムアウト時間 30分 ユーザー応答の待機上限
タイムアウト時の挙動 Draft PR作成 作業成果を保全
再開方法 PRページで承認/修正指示 Draft解除またはコメント

実装ガイドライン

  1. 承認待ち状態を明示: ⏸️ 承認待ち マークを必ず表示
  2. 番号選択形式を使用: 1/2/3 の番号で選択可能にする
  3. 選択肢を明確に: 3択（続行/修正/中断 or 下書き）を提示
  4. 次のアクションを予告: 承認後に何が起こるか説明
  5. 応答なしで進まない: ユーザー応答がない限りブロック

ワークフロー完了後の次ステップ選択

ワークフロー完了後、自動的に次のワークフローへ進むのではなく、ユーザーに選択肢を提示して次のアクションを決定させる。

対象ワークフロー

ワークフロー 完了後の選択肢 次ワークフロー
/req-workflow 基本設計に進む / 修正 / 終了 /basic-design-workflow
/basic-design-workflow 詳細設計に進む / 修正 / 終了 /detailed-design-workflow
/detailed-design-workflow 実装に進む / 修正 / 終了 /implement-issues

出力フォーマット（次ステップ選択）

---
## ✅ ワークフロー完了: {ワークフロー名}

### 成果物サマリー
| 項目 | 結果 |
|------|------|
| 最終スコア | X/10点 |
| 成果物 | `{file_path}` |
| ステータス | 合格 ✅ |

### 次のステップを選択してください

1. {次ワークフロー名}に進む（`{次ワークフローコマンド}`）
2. 成果物を修正する（指摘箇所をコメントしてください）
3. 一旦終了する

> 番号を選択してください（1-3）:
---

具体例

/req-workflow 完了後

---
## ✅ ワークフロー完了: 要件定義

### 成果物サマリー
| 項目 | 結果 |
|------|------|
| 最終スコア | 8/10点 |
| 成果物 | `docs/requirements/REQ-XXX-001_機能名.md` |
| ステータス | 合格 ✅ |

### 次のステップを選択してください

1. 基本設計に進む（`/basic-design-workflow`）
2. 要件定義書を修正する（指摘箇所をコメントしてください）
3. 一旦終了する

> 番号を選択してください（1-3）:
---

/basic-design-workflow 完了後

---
## ✅ ワークフロー完了: 基本設計

### 成果物サマリー
| 項目 | 結果 |
|------|------|
| 最終スコア | 9/10点 |
| 成果物 | `docs/designs/basic/BASIC-XXX-001_機能名.md` |
| ステータス | 合格 ✅ |

### 次のステップを選択してください

1. 詳細設計に進む（`/detailed-design-workflow`）
2. 基本設計書を修正する（指摘箇所をコメントしてください）
3. 一旦終了する

> 番号を選択してください（1-3）:
---

/detailed-design-workflow 完了後

---
## ✅ ワークフロー完了: 詳細設計

### 成果物サマリー
| 項目 | 結果 |
|------|------|
| 最終スコア | 9/10点 |
| 成果物 | `docs/designs/detailed/{機能名}/` |
| Epic Issue | #123 |
| 子Issue数 | 5件 |
| ステータス | 合格 ✅ |

### 次のステップを選択してください

1. 実装に進む（`/implement-issues`）
2. 詳細設計書を修正する（指摘箇所をコメントしてください）
3. 一旦終了する

> 番号を選択してください（1-3）:
---

ユーザー回答と対応アクション

回答 アクション
1 次のワークフローを自動実行（成果物パスを引数として渡す）
2 ユーザーの指摘を待ち、修正後に再レビュー
3 ワークフロー終了。成果物は保持

実装ガイドライン

  1. 必ず番号選択形式: ユーザーが明確に選択できるように番号を使用
  2. 自動実行しない: ユーザーが 1 を選択するまで次ワークフローは開始しない
  3. 成果物パスを引き継ぐ: 次ワークフローへの引数として成果物パスを渡す
  4. 終了時は成果物を明示: 「終了」選択時は成果物の場所と次回再開方法を提示

変更履歴

日付 変更内容
2026-01-17 承認ゲートを番号選択形式（1/2/3）に統一。テキスト入力から数字入力へ変更
2026-01-15 ワークフロー完了後の次ステップ選択パターンを追加
2026-01-12 ワークフロー別パラメータ表を追加。各コマンドからの参照を簡略化
2026-01-08 初版作成。各ワークフローから承認ゲートパターンを分離