start-workflow

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 選択時の分岐:

1. プロジェクトルートの .ralph/config.json の存在を確認する
2. 存在しない場合 → 案内してから終了: 「Autonomous mode には .ralph/config.json が必要です。先に /planning を実行して生成してください」
3. 存在する場合 → ユースケース選択（ステップ 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 等）

このスキルを使うスキル:

• なし（ユーザが直接呼び出す）