ワークフロー
ワークフローは、スラッシュコマンドまたは自然言語キーワードによってトリガーされる構造化されたマルチステッププロセスです。エージェントがタスクでどう協力するかを定義します。16のワークフローがあり、そのうち4つが永続的です（状態を維持し、誤って中断されません）。
永続ワークフロー
永続ワークフローはすべてのタスクが完了するまで実行を続けます。.agents/state/に状態を維持し、各ユーザーメッセージに[OMA PERSISTENT MODE: ...]コンテキストを再注入します。
/orchestrate
説明： 自動CLIベースの並列エージェント実行。CLIでサブエージェントをスポーンし、MCPメモリで調整、進捗を監視、検証ループを実行。
永続： はい。状態ファイル：.agents/state/orchestrate-state.json。
トリガーキーワード：
| 言語 | キーワード |
|---|---|
| 共通 | "orchestrate" |
| 英語 | "parallel", "do everything", "run everything" |
| 日本語 | "オーケストレート", "並列実行", "自動実行" |
| 韓国語 | "자동 실행", "병렬 실행", "전부 실행" |
| 中国語 | "编排", "并行执行", "自动执行" |
ステップ：
- Step 0 — 準備： スキル、コンテキストローディングガイド、メモリプロトコルを読み込み。ベンダーを検出。
- Step 1 — プランのロード/作成：
.agents/results/plan-{sessionId}.jsonを確認。なければ/planの実行を促す。 - Step 2 — セッション初期化：
oma-config.yamlをロード、セッションID生成、メモリにorchestrator-session.mdとtask-board.mdを作成。 - Step 3 — エージェントスポーン： 優先度ティアごとにスポーン。MAX_PARALLELを超えない。
- Step 4 — モニタリング：
progress-{agent}.mdをポーリング、task-board.mdを更新。 - Step 5 — 検証： 完了エージェントごとに
verify.shを実行。失敗時は再スポーン（最大2回）。2回後もだめならExploration Loopを起動。 - Step 6 — 収集： すべての
result-{agent}.mdを読み取りサマリーを取りまとめ。 - Step 7 — 最終レポート： セッションサマリーを提示。Quality Scoreを測定した場合はExperiment Ledgerのサマリーを含み、教訓を自動生成。
使用すべき場合： 自動協調による最大並列処理が必要な大規模プロジェクト。
/work
説明： ステップバイステップのマルチドメイン協調。PMがまず計画し、各ゲートでユーザー確認後にエージェントが実行、QAレビューと課題修正。
永続： はい。状態ファイル：.agents/state/work-state.json。
トリガーキーワード：
| 言語 | キーワード |
|---|---|
| 共通 | "work", "step by step" |
| 日本語 | "コーディネート", "ステップバイステップ" |
| 韓国語 | "코디네이트", "단계별" |
ステップ：
- Step 0 — 準備： スキル、コンテキストローディング、メモリプロトコルを読み込み。
- Step 1 — 要件分析： 関連ドメインを特定。
- Step 2 — PMエージェント計画： 要件分解、APIコントラクト定義、
.agents/results/plan-{sessionId}.jsonに保存。 - Step 3 — プランレビュー： ユーザーにプランを提示。確認必須。
- Step 4 — エージェントスポーン： 優先度ティアごとにスポーン。
- Step 5 — モニタリング： 進捗ポーリング、APIコントラクト整合性検証。
- Step 6 — QAレビュー： セキュリティ、パフォーマンス、アクセシビリティ、コード品質。
- Step 7 — 反復： CRITICAL/HIGH課題は再スポーン。同問題2回失敗でExploration Loop。
使用すべき場合： ステップバイステップの制御と各ゲートでのユーザー承認が必要な機能。
/ultrawork
説明： 品質にこだわるワークフロー。5フェーズ、17ステップ合計、うち11がレビューステップ。
永続： はい。状態ファイル：.agents/state/ultrawork-state.json。
トリガーキーワード： "ultrawork", "ulw"（共通）
フェーズとステップ：
| フェーズ | ステップ | エージェント | レビュー観点 |
|---|---|---|---|
| PLAN | 1-4 | PMエージェント（インライン） | 完全性、メタレビュー、過剰エンジニアリング/シンプルさ |
| IMPL | 5 | 開発エージェント（スポーン） | 実装 |
| VERIFY | 6-8 | QAエージェント（スポーン） | 整合性、安全性（OWASP）、回帰防止 |
| REFINE | 9-13 | デバッグエージェント（スポーン） | ファイル分割、再利用性、カスケード影響、一貫性、デッドコード |
| SHIP | 14-17 | QAエージェント（スポーン） | コード品質、UXフロー、関連課題、デプロイ準備 |
ゲート定義：
- PLAN_GATE： プラン文書化、前提リスト化、代替案検討、ユーザー確認。
- IMPL_GATE： ビルド成功、テストパス、計画ファイルのみ変更。
- VERIFY_GATE： CRITICALゼロ、HIGHゼロ、回帰なし、Quality Score >= 75。
- REFINE_GATE： 大ファイルなし（500行超/50行超）、Quality Score非劣化。
- SHIP_GATE： 品質チェックパス、UX検証、最終承認。
ゲート失敗時： 1回目は修正して再試行。同問題2回目でExploration Loop起動。
使用すべき場合： 最高品質のデリバリー。プロダクション準備完了が必要な場合。
/ralph
説明： 永続的な自己参照実行ループ。ultrawork を独立したベリファイアでラップし、各イテレーション後に完了基準をチェック。すべての基準が通過するか、セーフガードが発動するまでループを継続します。
永続： はい。状態ファイル：.agents/state/ralph-state.json。
トリガーキーワード：
| 言語 | キーワード |
|---|---|
| 共通 | "ralph" |
| 英語 | "don't stop", "until done", "keep going", "finish everything", "run to completion" |
| 韓国語 | "랄프", "멈추지마", "끝까지", "완료될때까지", "끝장내" |
| 日本語 | "止まるな", "完了まで", "最後まで", "全部終わらせて" |
| 中国語 | "不要停", "直到完成", "全部完成", "做完为止" |
| スペイン語 | "no pares", "hasta completar", "termina todo" |
| フランス語 | "n'arrête pas", "jusqu'à complétion", "termine tout" |
| ドイツ語 | "hör nicht auf", "bis zur fertigstellung", "alles fertigstellen" |
フェーズ：
- Phase 0 — INIT： 前提条件をロード（context-loading、メモリプロトコル、judge プロトコル）。検証可能な完了基準を定義（各基準は機械的に検証可能であること — テストのパス、ビルド成功、ファイル存在など）。基準をユーザーに提示して確認。
max_iterations: 5でセッション初期化。 - Phase 1 — WORK： ultrawork（PLAN → IMPL → VERIFY → REFINE → SHIP）を 1 イテレーションとして実行。
- Phase 2 — JUDGE： 独立したベリファイアが各完了基準を実際のプロジェクト状態と照合（テスト実行、ビルド確認、ファイル存在検証）。各基準を PASS/FAIL で採点し、エビデンスを添付。
- Phase 3 — DECIDE： すべての基準が PASS → ループ終了、最終レポート生成。いずれかが FAIL → イテレーションカウンタを増加、失敗コンテキストをフィードバックして Phase 1 に戻る。
- セーフガード：
current_iteration >= max_iterations（デフォルト 5）に達した場合、または同じ基準が同じ根本原因で連続 3 回失敗した場合（スタック検知）にループ停止。
/ultrawork との主な違い： ultrawork は 1 パスの 5 フェーズワークフロー。ralph は ultrawork を独立した judge が客観的に完了を検証するリトライループでラップします — 「レビュー完了」ではなく、実際に作業が完了するまで継続します。
読み込むファイル： .agents/workflows/ralph/resources/judge-protocol.md、および ultrawork の全ファイル。
書き込むファイル： session-ralph.md（メモリ）、イテレーションログ、最終レポート。
使用すべき場合： 確実な完了が必要な場合 — 1 回パスしてレポートするのではなく、検証可能な基準が通過するまでエージェントが作業を続ける必要があるとき。
非永続ワークフロー
/plan
説明： PM主導のタスク分解。要件分析、技術スタック選択、優先タスク分解、APIコントラクト定義。
トリガーキーワード： "task breakdown"（共通）、"plan"（英語）、"計画"、"要件分析"、"タスク分解"（日本語）
実行： インライン。/orchestrateや/workで使用。出力：.agents/results/plan-{sessionId}.json。
/exec-plan
説明： docs/exec-plans/に実行プランをファーストクラスのリポジトリアーティファクトとして作成・管理・追跡。
トリガーキーワード： なし（明示的呼び出しのみ）。
ステップ： 準備 -> スコープ分析（複雑度の評価：Simple/Medium/Complex）-> 実行プラン作成（docs/exec-plans/active/にMarkdown）-> APIコントラクト定義（境界をまたぐ場合）-> ユーザーレビュー -> 実行（/orchestrateまたは/workにハンドオフ）-> 完了（completed/に移動）。
出力： docs/exec-plans/active/{plan-name}.md（タスクテーブル、決定ログ、進捗ノート付き）。
使用すべき場合： 決定ログ付きの追跡実行が必要な複雑な機能で、/planの後。
/brainstorm
説明： デザインファーストのアイデア出し。意図探索、制約明確化、アプローチ提案、設計ドキュメント作成。
トリガーキーワード： "brainstorm"（共通）、"ブレインストーミング"、"アイデア"、"設計探索"（日本語）
ルール： デザイン承認前に実装や計画なし。コード出力なし。YAGNI。
/architecture
説明： ソフトウェアアーキテクチャワークフロー — アーキテクチャ問題を診断し、適切な分析手法（診断ルーティング / design-twice / ATAM / CBAM / ADR）を選択し、選択肢を比較し、ステークホルダーの意見を統合し、推奨案・レビュー・ADRを生成します。
トリガーキーワード： "architecture"、"ADR"、"ATAM"、"CBAM"（共通）、"architecture review"、"architectural tradeoff"（英語）、"アーキテクチャ"（日本語）、"아키텍처"、"설계 검토"（韓国語）、"架构"（中国語）
ステップ： 決定のフレーミング（新規アーキテクチャ / レビュー / トレードオフ分析 / 投資優先順位付け / ADR作成） -> 診断ルーティングで方法論を選択 -> MCPコード解析（get_symbols_overview、find_symbol、find_referencing_symbols）で現在のアーキテクチャを分析 -> ステークホルダーの意見を統合（コストを正当化できるほど横断的な場合のみ） -> 明示的な前提、トレードオフ、リスク、検証ステップを含む推奨案を生成 -> 実装が必要な場合は/planにハンドオフ。
ルール： このワークフローでは実装コードやタスク計画を記述しません。アーキテクチャ決定後に/planにハンドオフ。MCPツールを一貫して使用し、生のファイル読み取りやgrepで代替しません。
使用すべき場合： システムアーキテクチャの選択、モジュール/サービス/所有権境界の決定、リファクタ優先順位付け、ADR作成、アーキテクチャ上の痛み（変更増幅、隠れた依存関係、扱いにくいAPI）の調査。
/deepinit
説明： 完全なプロジェクト初期化。コードベース分析、AGENTS.md、ARCHITECTURE.md、docs/知識ベース生成。
トリガーキーワード： "deepinit"（共通）、"プロジェクト初期化"（日本語）
/review
説明： 完全なQAレビューパイプライン。OWASP Top 10セキュリティ監査、パフォーマンス分析、WCAG 2.1 AAアクセシビリティ、コード品質レビュー。
トリガーキーワード： "code review"、"security audit"（共通）、"レビュー"、"コードレビュー"、"セキュリティ監査"（日本語）
オプションの修正-検証ループ（--fix付き）：QAレポート後にCRITICAL/HIGH課題を修正、最大3回繰り返し。
/debug
説明： 構造化されたバグ診断と修正。回帰テスト作成と類似パターンスキャン。
トリガーキーワード： "debug"（共通）、"デバッグ"、"バグ修正"、"エラー修正"（日本語）
サブエージェントスポーン基準： エラーが複数ドメインにまたがる、スキャンスコープ10ファイル超、深い依存関係トレースが必要。
/design
説明： 7フェーズデザインワークフロー。DESIGN.md、トークン、コンポーネントパターン、アクセシビリティルールを生成。
トリガーキーワード： "design system"、"DESIGN.md"、"design token"（共通）、"デザイン"、"ランディングページ"、"デザインシステム"（日本語）
フェーズ： SETUP -> EXTRACT -> ENHANCE -> PROPOSE -> GENERATE -> AUDIT -> HANDOFF
/scm
説明： 自動機能ベース分割付きConventional Commits生成。
トリガーキーワード： なし（明示的呼び出しのみ）。
/tools
説明： MCPツールの可視性と制限の管理。ツールグループの有効化/無効化。
トリガーキーワード： なし（明示的呼び出しのみ）。
ツールグループ： memory、code-analysis、code-edit、file-ops
/pdf
説明： opendataloader-pdfを用いてPDFをMarkdownに変換 — 正しい読み順でテキスト、表、見出し、画像を抽出します。
トリガーキーワード： なし（入力ファイルパスを指定して明示的に呼び出し）。
ステップ： 入力検証（ファイル存在確認） -> 出力場所の決定（ユーザー指定または入力と同じディレクトリ） -> uvx opendataloader-pdfを実行（インストール不要） -> スキャンPDFにはOCR付きハイブリッドモードを使用 -> uvx mdformatで出力を正規化 -> 可読性と構造を検証 -> 変換に関する問題（表の欠落、文字化け）を報告。
ルール： デフォルトの出力場所は入力PDFと同じディレクトリ。ステップを決してスキップしません。応答言語は.agents/oma-config.yamlに従います。
使用すべき場合： LLMコンテキストまたはRAG取り込みのためのPDFドキュメントのMarkdown変換、PDFからの構造化コンテンツ（表、見出し、リスト）抽出。
/stack-set
説明： プロジェクト技術スタック自動検出とバックエンドスキル用言語固有リファレンス生成。
トリガーキーワード： なし（明示的呼び出しのみ）。出力：.agents/skills/oma-backend/stack/。
スキル vs ワークフロー
| 側面 | スキル | ワークフロー |
|---|---|---|
| 定義 | エージェントの専門知識 | オーケストレーションプロセス |
| 場所 | .agents/skills/oma-{name}/ | .agents/workflows/{name}.md |
| アクティベーション | スキルルーティングキーワードにより自動 | スラッシュコマンドまたはトリガーキーワード |
| スコープ | 単一ドメイン実行 | マルチステップ、多くの場合マルチエージェント |
自動検出の仕組み
フックシステム
UserPromptSubmitフックが各メッセージ処理前に実行されます：
triggers.json：11言語のキーワード-ワークフローマッピングを定義。keyword-detector.ts：入力をトリガーキーワードに対してスキャン、ワークフローコンテキストを注入。persistent-mode.ts：アクティブ状態ファイルを確認し永続ワークフロー実行を強制。
検出フロー
- ユーザーが自然言語入力
- 明示的
/commandの存在を確認（あればスキップ） triggers.jsonキーワードリストに対してスキャン- 情報パターンチェック（「とは」「って何」「どうやって」「説明して」）
- 情報的な場合はフィルタリング（ワークフロー非トリガー）
- アクション可能な場合、
[OMA WORKFLOW: {name}]を注入
除外ワークフロー
自動検出から除外（明示的/commandが必要）：/scm、/tools、/stack-set、/exec-plan、/pdf
永続モードの仕組み
状態ファイル
.agents/state/
├── orchestrate-state.json
├── ultrawork-state.json
└── work-state.json
ワークフロー名、現在のフェーズ/ステップ、セッションID、タイムスタンプ、および保留中の状態を含みます。
再注入
永続ワークフローがアクティブな間、persistent-mode.tsフックが各ユーザーメッセージに[OMA PERSISTENT MODE: {workflow-name}]を注入します。これにより、会話ターンをまたいでもワークフローの実行が継続されます。
非アクティブ化
永続ワークフローを無効にするには、ユーザーが「workflow done」（または設定言語の同等表現）と言います。これにより：
.agents/state/から状態ファイルを削除- 永続モードコンテキストの注入を停止
- 通常動作に復帰
すべてのステップが完了し最終ゲートを通過した場合にも自然終了します。
典型的なワークフローシーケンス
クイック機能
/plan → 出力レビュー → /exec-plan
複雑なマルチドメインプロジェクト
/work → PM計画 → ユーザー確認 → エージェントスポーン → QAレビュー → 課題修正 → 出荷
最高品質デリバリー
/ultrawork → PLAN（4レビュー）→ IMPL → VERIFY（3レビュー）→ REFINE（5レビュー）→ SHIP（4レビュー）
バグ調査
/debug → 再現 → 根本原因 → 最小修正 → 回帰テスト → 類似パターンスキャン
デザインから実装へ
/brainstorm → 設計ドキュメント → /plan → タスク分解 → /orchestrate → 並列実装 → /review → /scm
新規コードベースセットアップ
/deepinit → AGENTS.md + ARCHITECTURE.md + docs/