Menü
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | start-workflow |
| description | ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する |
タスクのユースケースを選択し、適切なワークフローパスを決定して、各ステップを順に実行する。
入力: ユーザのタスク説明 出力: ワークフロー完了（コミット + 振り返りまで）
原則: ワークフローの選択と進行を自動化し、ステップの漏れを防ぐ。
ユースケースを確認せずにワークフローを開始するな
常に:
例外:
AskUserQuestion でモードを選択する:
「このセッションの実行モードを選んでください」
| # | モード | 説明 |
|---|---|---|
| 1 | Interactive | 通常の人間協調モード（既定）。各ステップで人間が確認・承認を行う |
| 2 | Autonomous | Ralph Autonomous mode。.ralph/config.json に従い loop 実行。[1][2][3] を事前確定後、[4]-[11] は代替ゲートで自律実行 |
Autonomous 選択時の分岐:
.ralph/config.json の存在を確認する.ralph/config.json が必要です。先に /planning を実行して生成してください」runner/ralph-autonomous/start-tmux.sh 起動手順を案内する（Phase 3 実装後に利用可能）Interactive 選択時: 次のステップ（1. ユースケース選択）へ進む
ADR 0022: Autonomous/Interactive モード切替は
/start-workflowで毎回明示選択する
AskUserQuestion でユーザに確認する:
「どんな作業ですか？」
| # | ユースケース | 説明 |
|---|---|---|
| 1 | 機能開発 | 新機能の追加。設計判断を伴う |
| 2 | バグ修正 | 既存機能の不具合修正 |
| 3 | ドキュメント更新 | ドキュメントの追加・修正 |
| 4 | テスト修正・追加 | テストの修正または新規追加 |
| 5 | リファクタリング | 振る舞いを変えずにコードを改善 |
| 6 | 設定変更 | 設定ファイルの変更、依存更新等 |
ユースケースに応じて実行するステップを決定し、ユーザに表示する。
| ユースケース | 規模 | 実行ステップ |
|---|---|---|
| 機能開発 | 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]振り返り
各ステップを順に実行する。各ステップの前にユーザに確認する。
表示フォーマット:
━━━ [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 |
サスペンションポイント（[1]要件確定、[2]設計承認、[3]計画承認、[8]レビュー指摘対応、[11]コミット前）では、該当スキルの承認フローに従う。start-workflow は追加の承認を求めない（各スキルが自身の承認を処理する）。
バグ修正・リファクタリングの [1]要件(簡易) は /requirements スキルを呼ばず、以下を対話で確認するだけ:
全ステップ完了後:
━━━ ワークフロー完了 ━━━
ユースケース: バグ修正（Small）
実行ステップ: [1] → [4] → [5] → [8] → [9] → [11] → [12]
コミット: abc1234
| 合理化 | 反論 |
|---|---|
| 「小さい変更だからワークフロー不要」 | 設定変更（Tiny）パスがある。それを使え |
| 「バグ修正にレビューは不要」 | Small でもレビューは含まれる。1ファイルでもセキュリティリスクはある |
| 「ユースケースに当てはまらない」 | 最も近いものを選んで、進めながら調整する |
このスキルは委譲しない。 メインセッションが直接実行する。
start-workflow はオーケストレーションのみを行い、各ステップの実行は該当スキルに委ねる。 start-workflow 自体はコードを書かない、ファイルを作成しない。
前提スキル:
必須ルール:
次のステップ:
このスキルを使うスキル:
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。