ワークフロー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作成前承認） |
承認ゲートの明示
承認が必要な中間ステップは、ドキュメント内で {{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-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番号を標準化 |
