ワークフロー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 |
実装完了自己チェック |
- |
- |
| 6.6 |
設計書整合性チェック |
- |
-(NGならPhase 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(実装完了自己チェック)、6.6(設計書整合性チェック) |
| 承認ゲート |
ユーザーの明示的承認が必要 |
2.5(設計承認)、4.5(Issue化前承認)、7.1(PR作成前承認) |
承認ゲートの明示
承認が必要な中間ステップは、ドキュメント内で @.claude/skills/approval-gate/SKILL.md を参照し、承認ゲートであることを明示する。
承認ゲート配置基準
| 条件 |
承認ゲート必須 |
| 外部成果物を生成する直前 |
✅ |
| 不可逆な操作の直前(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 |
実装
詳細は @.claude/skills/implement-subtask-rules/SKILL.md セクション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-29 |
Phase 6.6(設計書整合性チェック)を追加。統合漏れによる「死にコード」防止 |
| 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番号を標準化 |