| name | start-workflow |
| description | ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する |
Start Workflow（ワークフロー開始）
概要
タスクのユースケースを選択し、適切なワークフローパスを決定して、各ステップを順に実行する。
入力: ユーザのタスク説明
出力: ワークフロー完了（コミット + 振り返りまで）
原則: ワークフローの選択と進行を自動化し、ステップの漏れを防ぐ。
Iron Law
ユースケースを確認せずにワークフローを開始するな
いつ使うか
常に:
例外:
- 既にワークフローが進行中の場合（途中のステップから再開）
プロセス
0. モード選択
AskUserQuestion でモードを選択する:
「このセッションの実行モードを選んでください」
| # | モード | 説明 |
|---|
| 1 | Interactive | 通常の人間協調モード（既定）。各ステップで人間が確認・承認を行う |
| 2 | Autonomous | Ralph Autonomous mode。.ralph/config.json に従い loop 実行。[1][2][3] を事前確定後、[4]-[11] は代替ゲートで自律実行 |
Autonomous 選択時の分岐:
- プロジェクトルートの
.ralph/config.json の存在を確認する
- 存在しない場合 → 案内してから終了: 「Autonomous mode には
.ralph/config.json が必要です。先に /planning を実行して生成してください」
- 存在する場合 → ユースケース選択（ステップ 1）をスキップし、
runner/ralph-autonomous/start-tmux.sh 起動手順を案内する（Phase 3 実装後に利用可能）
Interactive 選択時: 次のステップ（1. ユースケース選択）へ進む
ADR 0022: Autonomous/Interactive モード切替は /start-workflow で毎回明示選択する
1. ユースケース選択
AskUserQuestion でユーザに確認する:
「どんな作業ですか？」
| # | ユースケース | 説明 |
|---|
| 1 | 機能開発 | 新機能の追加。設計判断を伴う |
| 2 | バグ修正 | 既存機能の不具合修正 |
| 3 | ドキュメント更新 | ドキュメントの追加・修正 |
| 4 | テスト修正・追加 | テストの修正または新規追加 |
| 5 | リファクタリング | 振る舞いを変えずにコードを改善 |
| 6 | 設定変更 | 設定ファイルの変更、依存更新等 |
2. ワークフローパスの決定
ユースケースに応じて実行するステップを決定し、ユーザに表示する。
| ユースケース | 規模 | 実行ステップ |
|---|
| 機能開発 | Normal | [1]要件 → [2]設計 → [3]計画 → [4]実装 → [5]テスト → [6]リファクタ → [7]品質テスト → [8]レビュー → [9]検証 → [10]整理 → [11]コミット → [12]振り返り |
| 機能開発（Large） | Large | /roadmap スキルへ委譲 → (planning → tdd → ... → commit) × N → [12]振り返り。各フェーズ開始時に [6][7][8] スキップ可否を明示確認する |
| バグ修正 | Small | [1]要件(簡易) → [4]実装 → [5]テスト → [8]レビュー → [9]検証 → [11]コミット → [12]振り返り |
| ドキュメント更新 | Small | [4]実装 → [8]レビュー → [9]検証 → [11]コミット → [12]振り返り |
| テスト修正・追加 | Small | [4]実装 → [5]テスト → [8]レビュー → [9]検証 → [11]コミット → [12]振り返り |
| リファクタリング | Normal | [1]要件(簡易) → [4]実装 → [5]テスト → [6]リファクタ → [7]品質テスト → [8]レビュー → [9]検証 → [10]整理 → [11]コミット → [12]振り返り |
| 設定変更 | Tiny | [4]実装 → [9]検証 → [11]コミット |
表示例:
ワークフロー: バグ修正（Small）
ステップ: [1]要件(簡易) → [4]実装 → [5]テスト → [8]レビュー → [9]検証 → [11]コミット → [12]振り返り
3. ステップ実行
各ステップを順に実行する。各ステップの前にユーザに確認する。
表示フォーマット:
━━━ [N] ステップ名 ━━━
スキル: /skill-name
説明: このステップで何をするか
進めますか？
ユーザが確認したら、該当スキルを実行する。
各ステップとスキルの対応:
| ステップ | スキル | 備考 |
|---|
| [1] 要件理解 | /requirements | 簡易版は対話でスコープだけ確認 |
| [2] 設計 | /design | |
| [3] 計画 | /planning | |
| [4] 実装 | /tdd | |
| [5] テスト | /tdd（継続） | [4]と一体で実行 |
| [6] リファクタ | /simplify | |
| [7] 品質テスト | /test-quality | |
| [8] レビュー | /code-review | |
| [9] 検証 | /verification | |
| [10] 整理 | /cleanup | |
| [11] コミット | /commit | |
| [12] 振り返り | /retrospective | |
4. 承認ゲート
サスペンションポイント（[1]要件確定、[2]設計承認、[3]計画承認、[8]レビュー指摘対応、[11]コミット前）では、該当スキルの承認フローに従う。start-workflow は追加の承認を求めない（各スキルが自身の承認を処理する）。
5. 簡易版ステップ
バグ修正・リファクタリングの [1]要件(簡易) は /requirements スキルを呼ばず、以下を対話で確認するだけ:
- 何を修正/改善するか（1-2文）
- 影響範囲（どのファイル/機能）
- 完了条件（どうなったら完了か）
6. 完了
全ステップ完了後:
━━━ ワークフロー完了 ━━━
ユースケース: バグ修正（Small）
実行ステップ: [1] → [4] → [5] → [8] → [9] → [11] → [12]
コミット: abc1234
よくある合理化
| 合理化 | 反論 |
|---|
| 「小さい変更だからワークフロー不要」 | 設定変更（Tiny）パスがある。それを使え |
| 「バグ修正にレビューは不要」 | Small でもレビューは含まれる。1ファイルでもセキュリティリスクはある |
| 「ユースケースに当てはまらない」 | 最も近いものを選んで、進めながら調整する |
危険信号
委譲指示
このスキルは委譲しない。 メインセッションが直接実行する。
start-workflow はオーケストレーションのみを行い、各ステップの実行は該当スキルに委ねる。
start-workflow 自体はコードを書かない、ファイルを作成しない。
Integration
前提スキル:
必須ルール:
- workflow — ワークフロー定義（State Machine、Safety Limits）
次のステップ:
- ユースケースに応じた最初のスキル（/requirements、/tdd 等）
このスキルを使うスキル:
