ワークフロー
このガイドは Rasen の一般的なワークフローパターンと各パターンをいつ使うかをカバーしています。基本的なセットアップについては はじめに を参照してください。コマンドリファレンスについては コマンド を参照してください。
哲学：ステージではなくアクション
従来のワークフローはあなたをステージを通じて強制します：計画、次に実装、次に完了。しかし実際の作業はきちんとボックスに収まりません。
OPSX は異なるアプローチを採ります：
Traditional (phase-locked):
PLANNING ────────► IMPLEMENTING ────────► DONE
│ │
│ "Can't go back" │
└────────────────────┘
OPSX (fluid actions):
proposal ──► specs ──► design ──► tasks ──► implement
主な原則:
- ステージではなくアクション - コマンドはあなたが立ち往生しているステージではなく、あなたができることです
- 依存関係は有効化条件 - 依存関係は何が必須かではなく何が可能かを示しています
カスタマイズ: OPSX ワークフローは成果物シーケンスを定義するスキーマで駆動されます。カスタムスキーマ作成の詳細は カスタマイズ を参照してください。
2 つのモード
クイックパス（core プロファイル）
新規インストールはデフォルトで full プロファイル（すべてのワークフロー）になります。core は毎日のリズムに切り替えられるスリム化されたプロファイルです：
/rasen:explore/rasen:propose/rasen:apply/rasen:sync/rasen:archive
一般的なフロー：
/rasen:explore ──► /rasen:propose ──► /rasen:apply ──► /rasen:sync ──► /rasen:archive
(optional)
探索から始めます（形成する価値のある習慣）
/rasen:explore はデフォルトプロファイルの一部です。高度な追加ではなく。問題はあるが計画がない場合に行う動きです。AI アシスタントの場合、ほとんどの場合。
You: /rasen:explore
AI: What would you like to explore?
You: Our search results feel stale. I'm not sure if it's caching,
indexing, or the query itself.
AI: Let me look... [reads the search service and cache layer]
It's the index: it only rebuilds nightly, so edits don't show
up until the next day. Two options: rebuild on write (simple,
more load) or a short-TTL cache invalidation (more moving parts,
less load). Given your write volume is low, rebuild-on-write is
the cleaner fix. Want to scope it?
You: Yes.
You: /rasen:propose rebuild-search-index-on-write
Explore は成果物を作成せず、コードを作成しません。曖昧な懸念を正確な変更に変える無料のノーリスク会話です。したがって、その後の提案は鋭いです。既に正確に何が必要かを知っていますか？スキップして直接 /rasen:propose に移動します。完全ガイド：探索を最初に。
拡張/フルワークフロー（カスタム選択）
明示的なスキャフォールドおよびビルドコマンド（/rasen:new, /rasen:continue, /rasen:ff, /rasen:verify, /rasen:bulk-archive, /rasen:onboard）はデフォルトで既にインストールされています。新規インストールはデフォルトで full プロファイルになるため。むしろ core セットだけに絞り込むを好む場合は、以下で切り替えます：
rasen config profile core
rasen update
ワークフローパターン（拡張モード）
クイック機能
構築する内容を知っていて実行する必要があるだけの場合：
/rasen:new ──► /rasen:ff ──► /rasen:apply ──► /rasen:verify ──► /rasen:archive
会話例:
You: /rasen:new add-logout-button
AI: Created rasen/changes/add-logout-button/
Ready to create: proposal
You: /rasen:ff
AI: Creating all planning artifacts...
✓ proposal.md
✓ specs/
✓ design.md
✓ tasks.md
Ready for implementation!
You: /rasen:apply
AI: Working through tasks...
✓ Added logout button to header
✓ Implemented session clearing
✓ Added confirmation dialog
All tasks complete!
You: /rasen:archive
AI: ✓ Merged specs
✓ Archived change
最適な用途: 小～中規模機能、バグ修正、単純な変更。
探索的
要件が不明か最初に調査する必要がある場合：
/rasen:explore ──► /rasen:new ──► /rasen:continue ──► ... ──► /rasen:apply
会話例:
You: /rasen:explore
AI: What would you like to explore?
You: I want to improve page load performance but I'm not sure
where the bottlenecks are.
AI: Let me help investigate...
[Analyzes bundle sizes, identifies slow queries, reviews
component render patterns]
I found three main bottlenecks:
1. Large unoptimized images
2. Synchronous data fetching in ProductList
3. Re-renders from context changes
Which would you like to address first?
You: Let's tackle the data fetching issue.
You: /rasen:new optimize-product-list-fetching
AI: Created change. Ready to create: proposal
You: /rasen:continue
AI: Creating proposal based on our exploration...
[Writes proposal incorporating investigation insights]
Ready to create: specs, design
Which would you like next?
You: /rasen:continue
AI: Creating specs...
最適な用途: パフォーマンス最適化、デバッグ、アーキテクチャ決定、不明な要件。
並列変更
複数の変更を同時に処理します：
Change A: /rasen:new ──► /rasen:ff ──► /rasen:apply (in progress)
│
context switch
│
Change B: /rasen:new ──► /rasen:ff ──────► /rasen:apply
会話例:
You: I'm working on add-dark-mode but got pulled into a bug fix
You: /rasen:new fix-login-redirect
AI: Created rasen/changes/fix-login-redirect/
You: /rasen:ff
AI: ✓ Created planning artifacts
You: /rasen:apply
AI: Working on fix-login-redirect...
[Implements the fix]
All tasks complete!
You: /rasen:archive
AI: ✓ Archived fix-login-redirect
You: Let's get back to dark mode
You: /rasen:apply add-dark-mode
AI: Resuming add-dark-mode...
Picking up at task 2.3: Update Header...
最適な用途: 並列作業ストリーム、緊急割り込み、チーム協力。
複数の完成した変更がある場合は、/rasen:bulk-archive を使用します：
You: /rasen:bulk-archive
AI: Found 3 completed changes:
- add-dark-mode (all tasks done)
- fix-login-redirect (all tasks done)
- update-footer (all tasks done)
Checking for spec conflicts...
⚠ add-dark-mode and update-footer both touch specs/ui/
Inspecting codebase to resolve...
Both changes are implemented. Will apply in chronological order.
Archive all 3 changes?
You: Yes
AI: ✓ Archived add-dark-mode
✓ Archived fix-login-redirect
✓ Archived update-footer
Specs merged in order: add-dark-mode → update-footer
一括アーカイブは複数の変更が同じ仕様に触れる場合を検出し、実装されている内容をチェックして競合を解決します。
変更を完成させる
推奨される完成フロー：
/rasen:apply ──► /rasen:verify ──► /rasen:archive
│ │
validates prompts to sync
implementation if needed
検証：作業をチェック
/rasen:verify は 3 つのディメンションにわたって実装を成果物に対して検証します：
You: /rasen:verify
AI: Verifying add-auth...
COMPLETENESS
✓ All 12 tasks in tasks.md are checked
✓ All requirements in specs have corresponding code
⚠ Scenario "Session timeout after inactivity" not tested
CORRECTNESS
✓ Implementation matches spec intent
✓ Edge cases from scenarios are handled
✓ Error states match spec definitions
COHERENCE
✓ Design decisions reflected in code structure
✓ Naming conventions consistent with design.md
⚠ Design mentions "event-driven" but implementation uses polling
SUMMARY
─────────────────────────────
Critical issues: 0
Warnings: 2
Ready to archive: Yes (with warnings)
Recommendations:
1. Add test for session timeout scenario
2. Consider refactoring to event-driven as designed, or update design.md
検証がチェックする内容:
| ディメンション | 検証内容 |
|---|---|
| 完全性 | すべてのタスク完了、すべての要件実装、シナリオ対応 |
| 正確性 | 実装が仕様の意図と一致、エッジケース処理 |
| 一貫性 | コードに反映された設計決定、一貫したパターン |
検証はアーカイブをブロックしませんが、最初に対処したい問題を表示します。
レビューサイクル：クリーンになるまでループ（オプト・イン）
/rasen:verify は単一パスです。/rasen:review-cycle は変更が実際にクリーンになるまでレビュアーをラップして実行を続けるループです：
review ──► triage ──► fix ──► re-review(Δ) ──► { pass | loop | escalate }
各レビューパスは常にインストールされている rasen-review エンジンに委任します — ループはレビューヒューリスティックを再実装しません。上に 4 つのことを追加します：
- 修正サイズトリアージ。 各検出結果は修正のサイズで経路指定されます：軽微 → オーケストレータインライン、重大 → コードを書いた実装エージェント、設計レベル → 別の修正エージェント（元の著者ではない）。
- 著者 ≠ 検証者。 検出結果は修正を作成しなかった レビュアーが元の検出結果に対して確認した場合のみ解決済みです。軽微なインラインの修正の場合、独立したゲート実行（テスト/リント/ビルド）と正確な変更の読み込みが同等の非著者チェック — そしてそれはサイクルレポートに記録される必要があります。
- デルタのみを再レビュー。 Claude Code とエージェントチーム（
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）の場合、リード はSendMessage経由で元のレビュアーを再開してデルタのみを再レビューできます（SendMessage を開始できるのはリード のみ）。そうでなければ、事前検出結果と修正差分を共有ファイル経由で新しいデルタレビューにフォールバック — 同等の結果、ただしコストが高くなります。 - 制限された終了。 ループは最大ラウンド（デフォルト 3）でキャップされます。上限に到達した未解決の Blocker/Major 検出結果でヒューマンにエスカレートして、オープン検出結果とラウンド履歴 — クリーン合格をサイレント報告することはありません。
実装後、ライブの差分に対して使用します。オプト・インです：カスタムプロファイル経由で有効にします（core にはありません）。ラウンド履歴と各非著者確認は変更ディレクトリの review-cycle-report.md に記録されます。
アーカイブ：変更を終了
/rasen:archive は変更を完成させてアーカイブに移動します：
You: /rasen:archive
AI: Archiving add-auth...
Artifact status:
✓ proposal.md exists
✓ specs/ exists
✓ design.md exists
✓ tasks.md exists (12/12 tasks complete)
Delta specs: Not yet synced to main
→ Would you like to sync now?
You: Yes
AI: ✓ Synced specs to rasen/specs/auth/spec.md
✓ Moved to rasen/changes/archive/2025-01-24-add-auth/
Change archived successfully.
アーカイブは仕様が同期されていない場合はプロンプトします。不完全なタスクでブロックしませんが、警告します。
何をいつ使うか
/rasen:ff 対 /rasen:continue
| 状況 | 使用 |
|---|---|
| 明確な要件、構築の準備ができている | /rasen:ff |
| 探索中、各ステップをレビューしたい | /rasen:continue |
| 仕様前に提案に関して反復したい | /rasen:continue |
| 時間的プレッシャー、速く動く必要がある | /rasen:ff |
| 複雑な変更、コントロール必要 | /rasen:continue |
経験則: 完全なスコープを事前に説明できる場合は /rasen:ff を使用します。進行に応じて理解している場合は /rasen:continue を使用します。
更新対新規開始
一般的な質問：既存の変更を更新する時と新しい変更を開始する時はいつですか？
既存の変更を更新する場合:
- 同じ意図、調整された実行
- スコープが狭くなる（MVP 最初、残りは後で）
- 学習駆動の修正（コードベースが予想と異なる）
- 実装発見に基づいた設計調整
新しい変更を開始する場合:
- 意図が根本的に変更
- スコープが異なる作業に爆発した
- 元の変更は単独で「完了」マークできる
- パッチはより明確にするより混乱させる
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW
例：「ダークモード追加」
- 「カスタムテーマも サポートする必要がある」→ 新しい変更（スコープ爆発）
- 「システム環境設定検出は予想以上に難しい」→ 更新（同じ意図）
- 「トグル最初出荷、環境設定は後で追加」→ 更新してアーカイブ、次に新しい変更
ベストプラクティス
変更をフォーカスさせておきます
1 つの論理的な作業単位あたり 1 つの変更。「機能 X を追加してまた Y をリファクタ」を行う場合は、2 つの分離された変更を検討します。
理由:
- 理解しやすくレビューしやすい
- クリーンなアーカイブ履歴
- 独立して出荷できます
- 必要な場合のシンプルなロールバック
要件が不明な場合は /rasen:explore を使用します
変更にコミットする前に、問題スペースを探索します：
You: /rasen:explore
AI: What would you like to explore?
You: How should we handle rate limiting for our API?
AI: Let me investigate your current setup and options...
[Researches codebase, considers patterns]
I see three approaches we could take:
1. Middleware-based (simple, per-endpoint)
2. Redis-backed (scalable, shared state)
3. Token bucket per user (fair, complex)
Your current stack suggests #1 or #2. What's your scale?
探索は成果物を作成する前に思考を明確にします。
アーカイブ前に検証します
/rasen:verify を使用して実装が成果物と一致することを確認します：
You: /rasen:verify
AI: Verifying add-dark-mode...
✓ All tasks in tasks.md are checked
✓ Requirements in specs have corresponding code
✓ Design decisions are reflected in implementation
Ready to archive!
変更を閉じる前に不一致を検出します。
変更を明確に命名します
良い名前は rasen list を有用にします：
Good: Avoid:
add-dark-mode feature-1
fix-login-redirect update
optimize-product-query changes
implement-2fa wip
コマンドクイックリファレンス
詳細なコマンドと選択肢については、コマンド を参照してください。
| コマンド | 目的 | いつ使うか |
|---|---|---|
/rasen:propose |
変更 + 計画成果物を作成 | 高速デフォルトパス（core プロファイル） |
/rasen:explore |
アイデアを AI と一緒に検討 | ここから始めます。要件が不明、調査、オプション比較 |
/rasen:new |
変更スキャフォールドを開始 | 拡張モード、明示的な成果物制御 |
/rasen:continue |
次の成果物を作成 | 拡張モード、ステップバイステップの成果物作成 |
/rasen:ff |
すべての計画成果物を作成 | 拡張モード、明確なスコープ |
/rasen:apply |
タスクを実装 | コード記述の準備ができている |
/rasen:verify |
実装を検証 | 拡張モード、アーカイブ前 |
/rasen:sync |
デルタ仕様をマージ | 拡張モード、オプション |
/rasen:archive |
変更を完成 | すべての作業が終了 |
/rasen:bulk-archive |
複数の変更をアーカイブ | 拡張モード、並列作業 |