When & Why to Use This Skill
This Claude skill establishes a standardized framework for workflow phase numbering, approval gate protocols, and retry limits across the entire development lifecycle. By unifying the structure of requirements, design, implementation, and release processes, it ensures consistent agent behavior, enhances process transparency, and maintains high-quality standards through rigorous review thresholds and a Single Source of Truth (SSOT) for quality metrics.
Use Cases
- Standardizing multi-stage AI workflows to ensure consistent phase naming and numbering across requirements, design, and implementation tasks.
- Implementing mandatory 'Approval Gates' (Phase 2.5/4.5) to require explicit human intervention before critical or irreversible actions like PR creation or production releases.
- Optimizing token consumption in implementation tasks by enforcing granular document reference rules (Phase 0.6) instead of full-file reading.
- Ensuring cross-workflow quality consistency by centralizing review score thresholds (SSOT) for technical documentation and code reviews.
- Managing complex project transitions by defining clear 'Phase 0.5' protocols for checking consistency with existing documents during incremental updates.
| name | workflow-phase-convention |
|---|
| description | 全ワークフローで一貫したPhase番号体系、承認ゲート規約、最大リトライ回数の標準を定義 |
|---|
ワークフローPhase命名規約
参照元: 全ワークフロー（req-workflow, basic-design-workflow, detailed-design-workflow, implement-issues, release-workflow）
概要
全ワークフローで一貫したPhase番号体系を使用し、ユーザーの理解を容易にする。
Phase番号体系
標準Phase構成
| Phase |
名称 |
目的 |
| Phase 0 |
コンテキスト収集 |
入力の解析、必要情報の収集 |
| Phase 0.5 |
既存ドキュメント整合性確認 |
既存成果物との整合性チェック（追加仕様時のみ） |
| Phase 0.6 |
設計書参照ルール |
トークン最適化のための部分参照（実装系のみ） |
| Phase 1 |
主要作業（作成/実装） |
ワークフローの主目的を実行 |
| Phase 2 |
レビューループ |
品質保証のための反復レビュー |
| Phase 2.5 |
ユーザー承認ゲート |
次フェーズ移行前の明示的承認 |
| Phase 3 |
後処理/成果物出力 |
最終出力、次ワークフローへの引き継ぎ |
拡張Phase（大規模ワークフロー用）
| Phase |
名称 |
使用例 |
| Phase 1.5 |
中間検証 |
ASCII禁止チェック、モックアップ検証 |
| Phase 4 |
追加作業 |
Issue作成、テスト項目書作成 |
| Phase 4.5 |
追加承認ゲート |
Issue化前の承認 |
| Phase 5+ |
実装固有フェーズ |
TDD、CI監視、PR作成 |
ワークフロー別Phase対応表
設計系ワークフロー（3フェーズ構成）
| Phase |
req-workflow |
basic-design-workflow |
detailed-design-workflow |
| 0 |
コンテキスト収集 |
コンテキスト収集 |
コンテキスト収集 |
| 0.5 |
既存要件整合性確認 |
技術ヒアリング + 既存設計確認 |
既存システム影響分析 |
| 1 |
要件定義書作成 |
基本設計書作成 |
詳細設計書作成 |
| 1.5 |
- |
- |
ASCII/モックアップ検証 |
| 2 |
レビューループ（5回） |
レビューループ（3回） |
レビューループ（3回） |
| 2.5 |
ユーザー承認ゲート |
ユーザー承認ゲート |
- |
| 3 |
成果物サマリー |
詳細設計準備 |
テスト項目書作成 |
| 4 |
- |
- |
Issue作成 |
| 4.5 |
- |
- |
ユーザー承認ゲート |
実装系ワークフロー（12+フェーズ構成）
| Phase |
implement-issues |
bug-fix-workflow |
ラベル |
| 0 |
ブランチ作成 |
バグ報告自動検出 |
phase:0-branch |
| 0.5 |
設計書存在チェック |
- |
- |
| 0.6 |
設計書参照ルール |
- |
- |
| 1 |
環境構築 |
Issue確認/作成 |
phase:1-env |
| 1.5 |
- |
環境選択 |
- |
| 2 |
設計書参照 |
/implement-issues呼出 |
phase:2-design |
| 3 |
設計書実現性チェック |
- |
phase:3-check |
| 4 |
TDD: Red |
- |
phase:4-red |
| 5 |
TDD: Green |
- |
phase:5-green |
| 6 |
TDD: Refactor |
- |
phase:6-refactor |
| 6.5 |
実装完了自己チェック |
- |
- |
| 7 |
品質レビュー |
- |
phase:7-review |
| 8 |
ストレステスト（任意） |
- |
phase:8-stress |
| 9 |
ユーザー承認 |
- |
phase:9-approval |
| 10 |
コミット & PR作成 |
PR作成 |
phase:10-pr |
| 11 |
CI監視 |
CI監視 |
phase:11-ci |
| 12 |
マージ & クローズ |
マージ |
phase:12-merge |
リリース系ワークフロー（4フェーズ構成）
| Phase |
release-workflow |
説明 |
| 0.5 |
バージョン整合性チェック |
ハードコード検出（--skip-version-checkでスキップ可） |
| 1 |
バージョン提案 |
セマンティックバージョニング自動計算 |
| 2 |
ユーザー承認 |
承認ゲート（バージョン確定） |
| 3 |
リリース実行 |
バージョン更新→コミット→タグ→push→GitHub Release |
| 3.5 |
ワークフロー監視 |
Release Workflow完了待機 |
中間ステップ規約（Phase X.5）
定義
**X.5 Phase は「中間ステップ」**であり、必ずしも承認ゲートではない。
主要Phase間の補助的な処理を配置するための番号帯。
Phase X（主要作業） → Phase X.5（中間ステップ） → Phase X+1（次の作業）
中間ステップの種類
| 種類 |
説明 |
例 |
| 技術的中間処理 |
自動的な検証・記録処理 |
0.5-A（技術スタック選択）、0.6（設計書参照ルール）、1.5（モックアップ検証） |
| 条件分岐ポイント |
状況に応じた処理分岐 |
0.5-B（既存設計書確認）、6.5（実装完了自己チェック） |
| 承認ゲート |
ユーザーの明示的承認が必要 |
2.5（設計承認）、4.5（Issue化前承認）、7.1（PR作成前承認） |
承認ゲートの明示
承認が必要な中間ステップは、ドキュメント内で {{skill:approval-gate}} を参照し、承認ゲートであることを明示する。
承認ゲート配置基準
| 条件 |
承認ゲート必須 |
| 外部成果物を生成する直前 |
✅ |
| 不可逆な操作の直前（PR作成、Issue作成） |
✅ |
| 単なる中間処理 |
❌ |
Phase 0.5 の統一仕様
目的
既存プロジェクトへの追加仕様時に、既存ドキュメント・コードとの整合性を確認する。
実行条件
| 条件 |
Phase 0.5 |
| 新規プロジェクト |
スキップ |
| 既存プロジェクトへの追加 |
実行 |
| ユーザーが明示的にスキップ指示 |
スキップ |
共通出力フォーマット
## 既存ドキュメント整合性確認結果
### 関連する既存ドキュメント
| ドキュメント | 関連度 | 影響 |
|-------------|--------|------|
| {パス} | 高/中/低 | {影響内容} |
### 整合性チェック結果
| 項目 | ステータス | 備考 |
|------|----------|------|
| {チェック項目} | ✅ OK / ⚠️ 要確認 / ❌ 不整合 | {詳細} |
### 対応方針
1. 続行 → 整合性確認OK、次フェーズへ
2. 調整 → 既存ドキュメントと調整後に続行
3. 中断 → 確認後に再開
> 番号を選択してください（1-3）:
Phase 0.6 設計書参照ルール（実装系専用）
目的
設計書の全文読み込みを禁止し、必要なセクションのみを参照することでトークン消費を削減する。
適用対象
| ワークフロー |
Phase 0.6 |
| implement-issues |
✅ 適用 |
| bug-fix-workflow |
❌ 適用外（設計書なしで実行可） |
| 設計系ワークフロー |
❌ 適用外（全文参照が必要） |
参照ルール
| ルール |
詳細 |
| 禁止 |
設計書の全文読み込み |
| 必須 |
Subtaskに必要なセクションのみ参照 |
| 上限 |
2,000トークン/Subtask |
実装
詳細は {{skill:implement-subtask-rules}} セクション1を参照。
最大リトライ回数
| ワークフロー |
最大リトライ |
理由 |
| req-workflow |
5回 |
要件は曖昧になりやすく、反復が必要 |
| basic-design-workflow |
3回 |
技術的判断が明確、収束が早い |
| detailed-design-workflow |
3回 |
基本設計に基づくため収束が早い |
| implement-issues |
3回 |
コードは客観的に検証可能 |
レビュースコア閾値 ★SSOT★
このセクションがレビュースコア閾値の唯一の定義（Single Source of Truth）です。
他ファイルで閾値を記載する場合は、このセクションへの参照を併記してください。
| ワークフロー |
合格閾値 |
理由 |
| req-workflow |
8点 |
要件は反復精緻化が前提、早期に次工程へ進める |
| basic-design-workflow |
9点 |
アーキテクチャ決定は後工程への影響大 |
| detailed-design-workflow |
9点 |
実装品質に直結 |
| implement-issues |
9点 |
本番コードは高品質必須 |
| reverse-engineer |
8点 |
既存コードからの推測のため完璧は困難 |
| infra-reviewer |
8点 |
インフラは複雑性を考慮し許容度を設定 |
Note: 8点閾値のワークフローは「早期フィードバック優先」の設計思想。
要件定義は後工程での修正が比較的容易なため、過度な完璧主義より進捗を優先する。
変更履歴
| 日付 |
変更内容 |
| 2026-01-17 |
release-workflowのPhase定義を追加（0.5→1→2→3→3.5） |
| 2026-01-16 |
レビュースコア閾値セクションに★SSOT★マーカー追加。各reviewer/skillファイルからSSOT参照を追加 |
| 2026-01-16 |
実装系Phase対応表をimplement-issues.mdの実際の定義に統一。Phase 6.5→実装完了自己チェック、Phase 7→品質レビュー、Phase 7.1→ユーザー承認に修正 |
| 2026-01-12 |
Phase X.5 規約を「中間ステップ」に再定義。承認ゲート限定→汎用的な中間処理に変更。種類分類（技術的中間処理/条件分岐/承認ゲート）を追加 |
| 2026-01-12 |
実装系Phase（0-12）を完全版に更新、レビュースコア閾値セクション追加 |
| 2026-01-12 |
Phase 0.6（設計書参照ルール）を追加。実装系ワークフロー表を更新 |
| 2026-01-08 |
初版作成。全ワークフローのPhase番号を標準化 |
