OPSX ワークフロー
Discord でのご意見をお待ちしています。
それは何ですか？
OPSX は rasen の標準的なワークフローになりました。
これは Rasen の変更のための 流動的でイテレーティブなワークフロー です。もう固いフェーズはありません。いつでも実行できるアクションだけです。
このワークフローが存在する理由
レガシーワークフローは機能しますが、ロックダウンされています：
- 指示がハードコーディングされている — TypeScript に埋め込まれていて、変更できません
- オールオアナッシング — 1 つの大きなコマンドがすべてを作成し、個別のピースをテストできません
- 固定構造 — 誰もが同じワークフロー、カスタマイズできません
- ブラックボックス — AI の出力が悪い場合、プロンプトをいじることができません
OPSX はそれを開きます。 誰もが次のことができます：
- 指示を試験的に使う — テンプレートを編集して、AI がより良い結果を出すかどうかを確認します
- 細かくテストする — 各成果物の指示を独立して検証します
- ワークフローをカスタマイズする — 独自の成果物と依存関係を定義します
- 迅速に反復する — テンプレートを変更して、すぐにテスト、リビルド不要
レガシーワークフロー： OPSX：
┌────────────────────────┐ ┌────────────────────────┐
│ パッケージ内に │ │ schema.yaml │◄── これを編集
│ ハードコードされている │ │ templates/*.md │◄── または這れを
│ ↓ │ │ ↓ │
│ 新しいリリースを待つ │ │ 即座に効果を発揮 │
│ ↓ │ │ ↓ │
│ それがより良いことを願う │ │ 自分で試験してください │
└────────────────────────┘ └────────────────────────┘
これは誰もが対象です：
- チーム — 実際にどのように機能しているかに合わせたワークフローを作成します
- パワーユーザー — プロンプトをいじってコードベースに対してより良い AI 出力を得ます
- Rasen 貢献者 — リリースなしで新しいアプローチを試験します
私たちはすべて、何が最も良く機能するかを学んでいます。OPSX により、一緒に学ぶことができます。
ユーザーエクスペリエンス
線形ワークフローの問題： あなたは「計画フェーズにいる」、次に「実装フェーズにいる」、次に「完了」と言えます。しかし、実際のことはそのようには機能しません。何かを実装して、設計が間違っていたことに気づき、仕様を更新して、実装を続ける必要があります。線形フェーズは、実際の仕事の方法に反します。
OPSX アプローチ：
- フェーズではなくアクション — 作成、実装、更新、アーカイブ — いつでも実行できます
- 依存関係はイネーブラー — 必要なことを示していますが、次に必要な作業ではありません
提案 ──→ 仕様 ──→ 設計 ──→ タスク ──→ 実装
セットアップ
# Rasen がインストールされていることを確認してください — スキルは自動的に生成されます
rasen init
これにより、AI コーディングアシスタントが自動検出する .claude/skills/ （または同等の）にスキルが作成されます。
デフォルトでは、rasen は full ワークフロープロファイルを使用します — すべてのワークフロー、拡張コマンド（new、continue、ff、verify、bulk-archive、onboard）を含みます。日常的な core セット（propose、explore、apply、sync、archive）に減らしたい場合は、rasen config profile core で切り替えて rasen update で適用してください。
セットアップ中に、プロジェクト設定（rasen/config.yaml）を作成するよう求められます。これはオプションですが、推奨されます。
プロジェクト設定
プロジェクト設定により、デフォルトを設定し、プロジェクト固有のコンテキストをすべての成果物に注入できます。
設定を作成する
設定は rasen init 中に、または手動で作成されます：
# rasen/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flows
設定フィールド
| フィールド | 型 | 説明 |
|---|---|---|
schema |
文字列 | 新しい変更のデフォルトスキーマ（例：spec-driven） |
context |
文字列 | すべての成果物の指示に注入されるプロジェクトコンテキスト |
rules |
オブジェクト | 成果物 ID でキー付けされた成果物ごとのルール |
動作方法
スキーマの優先順位（最高から最低）：
- CLI フラグ（
--schema <name>） - 変更メタデータ（変更ディレクトリ内の
.openspec.yaml） - プロジェクト設定（
rasen/config.yaml） - デフォルト（
spec-driven）
コンテキスト注入：
- コンテキストはすべての成果物の指示に前置されます
<context>...</context>タグでラップされます- AI がプロジェクトのコンベンションを理解するのに役立ちます
ルール注入：
- ルールは一致する成果物にのみ注入されます
<rules>...</rules>タグでラップされます- コンテキストの後、テンプレートの前に表示されます
スキーマ別の成果物 ID
spec-driven（デフォルト）：
proposal— 変更提案specs— 仕様design— 技術設計tasks— 実装タスク
設定検証
rules内の未知の成果物 ID は警告を生成します- スキーマ名は利用可能なスキーマに対して検証されます
- コンテキストは 50KB のサイズ制限があります
- 無効な YAML は行番号とともに報告されます
トラブルシューティング
「Unknown artifact ID in rules: X」
- 成果物 ID がスキーマと一致することを確認します（上記のリストを参照）
rasen schemas --jsonを実行して、各スキーマの成果物 ID を確認します
設定が適用されていません：
- ファイルが
rasen/config.yamlにあることを確認します（.ymlではなく） - YAML 構文をバリデーターで確認します
- 設定の変更は即座に有効になります（再起動は不要）
コンテキストが大きすぎます：
- コンテキストは 50KB に制限されています
- 外部ドキュメントを要約するか、リンクします
コマンド
| コマンド | 説明 |
|---|---|
/rasen:propose |
変更を作成し、計画成果物をワンステップで生成します（デフォルトクイックパス） |
/rasen:explore |
アイデアを考え抜き、問題を調査し、要件を明確にします |
/rasen:new |
新しい変更スキャフォールドを開始します（拡張ワークフロー） |
/rasen:continue |
次の成果物を作成します（拡張ワークフロー） |
/rasen:ff |
計画成果物を高速化します（拡張ワークフロー） |
/rasen:apply |
タスクを実装し、必要に応じて成果物を更新します |
/rasen:verify |
成果物に対する実装を検証します（拡張ワークフロー） |
/rasen:sync |
delta 仕様をメインに同期します（デフォルトワークフロー、オプション） |
/rasen:archive |
完了したらアーカイブします |
/rasen:bulk-archive |
完了した複数の変更をアーカイブします（拡張ワークフロー） |
/rasen:onboard |
エンドツーエンドの変更のガイド付きウォークスルー（拡張ワークフロー） |
使用方法
アイデアを探索する
/rasen:explore
アイデアを考え抜き、問題を調査し、オプションを比較します。構造は必要ありません。考える相棒です。洞察が結晶化したら、/rasen:propose（デフォルト）または /rasen:new//rasen:ff（拡張）に切り替えます。
新しい変更を開始する
/rasen:propose
変更を作成し、実装前に必要な計画成果物を生成します。
拡張ワークフローを有効にしている場合は、代わりに次を使用できます：
/rasen:new # スキャフォールドのみ
/rasen:continue # 一度に 1 つの成果物を作成
/rasen:ff # すべての計画成果物を一度に作成
成果物を作成する
/rasen:continue
依存関係に基づいて作成の準備ができているものを表示し、1 つの成果物を作成します。繰り返し使用して変更を段階的に構築します。
/rasen:ff add-dark-mode
すべての計画成果物を一度に作成します。構築しようとしていることが明確な場合に使用します。
実装する（流動的な部分）
/rasen:apply
タスクを処理し、進捗するにつれてそれらをチェックオフします。複数の変更をやり取りしている場合は、/rasen:apply <name> を実行できます。そうでなければ、会話から推測する必要があり、推測できない場合は選択するよう求められます。
完了する
/rasen:archive # 完了したらアーカイブに移動します（必要な場合は仕様を同期するよう促します）
ゴール駆動のイテレーション（/rasen:goal）
/rasen:auto はプロダクトがコード変更ドキュメント（propose → apply → ship）であると仮定します。いくつかのタスクはその形に適合しません — それらの「完了」は 条件 です：Lighthouse スコアを 90 に推進する、モジュールをルーブリッククリーンにする、研究する、簡潔に書く。/rasen:goal がそれらのエントリーポイントです。これは修正 → 判定を繰り返し、ゲートが満たされるまたはラウンドキャップがヒットするまでです。
1 つのコマンドを見ます。LEAD はタスクを分類し、1 つのバックエンドパイプラインを選択します（明示的なオーバーライドが常に優先）：
| セレクタ / キーワード | バックエンドパイプライン | ゲート | テール |
|---|---|---|---|
measure — score latency lighthouse benchmark p99 memory |
goal-loop-measure | 決定論的なコマンドが {score, passed} を発します |
ship → archive |
evaluate — rubric quality clean standard |
goal-loop-evaluate | 新しい評論者ワーカーが {satisfied, gaps} を判定 |
ship → archive |
research — research investigate write brief autoresearch |
goal-loop-research | 新しい評論者ワーカー | report（ship なし） |
フローは define-goal → iterate → tail：計画者は goal-plan.md（ゴール、ゲート、作成物、maxRounds）を書き、実装者はラウンド全体で温かく再利用され、各ラウンドの判定は goal-run.json（権威のあるループ位置）に追加され、実行は maxRounds（デフォルト 5）+ loopStallLimit（デフォルト 2）によって制限されます。/rasen:goal は /rasen:auto と同じ編成の遊び本をシェアします — 別のシステムではなく、兄弟エントリー。フルチャプター、処理された例、履歴セマンティクス、失速ラダーについては、repo の docs/ ディレクトリの opsx-workflow-guide.md §9（ゴール駆動のイテレーション）を参照してください。
いつ更新するか、いつ最初から開始するか
実装前に提案または仕様を編集することはいつでもできます。しかし、いつリファインが「これは異なる作業」になるのですか？
提案が何を取得するか
提案は 3 つのことを定義します：
- 意図 — どのような問題を解決していますか？
- スコープ — 範囲内/範囲外は何ですか？
- アプローチ — どのように解決しますか？
問題は：どのくらい変わったのか？
既存の変更を更新する場合：
同じ意図、洗練された実行
- あなたが考えなかったエッジケースを発見します
- アプローチは調整が必要ですが、ゴールは変わりません
- 実装は設計が少し外れていたことを明らかにします
スコープが縮小
- フルスコープが大きすぎて、最初に MVP を配布したいと気づきます
- 「ダークモードを追加」→ 「ダークモードトグルを追加（v2 でシステム設定）」
学習駆動型の修正
- コードベースは思った構造ではありません
- 依存関係が予想どおりに機能しません
- 「CSS 変数を使う」→ 「代わりに Tailwind の dark: プレフィックスを使う」
新しい変更を開始する場合：
意図が根本的に変わった
- 問題そのものが今では異なります
- 「ダークモードを追加」→ 「カスタムカラー、フォント、スペーシングを備えた包括的なテーマシステムを追加」
スコープが爆発的
- 変更は非常に大きくなり、本質的に異なる仕事です
- オリジナル提案は更新後は認識できなくなります
- 「ログインバグを修正」→ 「認証システムを書き直す」
オリジナルが完成可能
- 元の変更は「完了」とマークできます
- 新しい作業は単独で立つ、リファインではありません
- 完全にする「ダークモード MVP を追加」→ アーカイブ → 新しい変更「ダークモードを拡張」
ヒューリスティクス
┌─────────────────────────────────────┐
│ これは同じ仕事ですか？ │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
同じ意図ですか？ >50% 重なりますか？ オリジナル
同じ問題？ 同じスコープ？ これらの変更
│ │ なしで
│ │ 「完了」にできます？
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW
| テスト | 更新 | 新しい変更 |
|---|---|---|
| アイデンティティ | 「同じこと、洗練された」 | 「異なる仕事」 |
| スコープのオーバーラップ | >50% オーバーラップ | <50% オーバーラップ |
| 完成 | 変更なしで「完了」できません | オリジナルを完了、新しい仕事は単独で立つ |
| ストーリー | 更新チェーンはコヒーレントなストーリーを伝える | パッチは明確にするよりも混乱させます |
原則
更新はコンテキストを保持します。新しい変更は明確さを提供します。
あなたの考え方の履歴が価値がある場合に更新を選択してください。 パッチするより最初から開始する方が明確な場合に新しいを選択してください。
git ブランチのようにそれについて考えます：
- 同じ機能を操作しているときにコミットを続けます
- それが本当に新しい作業の場合は新しいブランチを開始します
- 時々部分的な機能をマージして、フェーズ 2 に対して最初から開始します
何が異なるのか？
レガシー（/openspec:proposal） |
OPSX（/rasen:*） |
|
|---|---|---|
| 構造 | 1 つの大きな提案ドキュメント | 依存関係を持つ独立した成果物 |
| ワークフロー | 線形フェーズ：計画 → 実装 → アーカイブ | 流動的なアクション — いつでも何でも実行 |
| イテレーション | もどるのに難しい | 学ぶにつれて成果物を更新します |
| カスタマイズ | 固定構造 | スキーマ駆動（独自の成果物を定義） |
キーの洞察： 仕事は線形ではありません。OPSX は前金をやめます。
アーキテクチャ深掘り
このセクションでは、OPSX がどのように機能するか、それがレガシーワークフローとどのように比較されるかを説明しています。
このセクションの例は、拡張コマンドセット（new、continue など）を使用しています。core プロファイルユーザーは、同じフローを propose → apply → sync → archive にマップできます。
哲学：フェーズ対アクション
┌─────────────────────────────────────────────────────────────────────────────┐
│ レガシーワークフロー │
│ （フェーズロック、オールオアナッシング） │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 計画 │ ───► │ 実装 │ ───► │ アーカイブ │ │
│ │ フェーズ │ │ フェーズ │ │ フェーズ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • すべての成果物を一度に作成します │
│ • 実装中に仕様に戻ることはできません │
│ • フェーズゲートは線形進行を強制します │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX ワークフロー │
│ （流動的なアクション、イテレーティブ） │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ アクション（フェーズではなく） │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ 任意の順序 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • 一度に 1 つの成果物を作成するか、高速化します │
│ • 実装中に仕様/設計/タスクを更新します │
│ • 依存関係はプログレスを有効にし、フェーズは存在しません │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
コンポーネントアーキテクチャ
レガシーワークフロー は TypeScript でハードコードされたテンプレートを使用します：
┌─────────────────────────────────────────────────────────────────────────────┐
│ レガシーワークフロー成分 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ハードコードされたテンプレート（TypeScript 文字列） │
│ │ │
│ ▼ │
│ ツール固有のコンフィギュレーター/アダプター │
│ │ │
│ ▼ │
│ 生成されたコマンドファイル（.claude/commands/openspec/*.md） │
│ │
│ • 固定構造、成果物認識なし │
│ • 変更にはコード変更 + リビルドが必要です │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
OPSX は外部スキーマと依存関係グラフエンジンを使用します：
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX コンポーネント │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ スキーマ定義（YAML） │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── 依存関係 │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── グロブパターン │ │
│ │ requires: [proposal] ◄── 提案後に有効化 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 成果物グラフエンジン │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • トポロジカルソート（依存関係順序付け） │ │
│ │ • 状態検出（ファイルシステム存在） │ │
│ │ • リッチ指示生成（テンプレート + コンテキスト） │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ スキルファイル（.claude/skills/rasen-*/SKILL.md） │
│ │
│ • クロスエディター互換（Claude Code、Cursor、Windsurf） │
│ • CLI でのスキルクエリ構造化データ │
│ • スキーマファイルを使用して完全にカスタマイズ可能 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
依存関係グラフモデル
成果物は有向非循環グラフ（DAG）を形成します。依存関係は イネーブラー、ゲートではありません：
提案
（ルートノード）
│
┌─────────────┴─────────────┐
│ │
▼ ▼
仕様 設計
（requires： （requires：
提案） 提案）
│ │
└─────────────┬─────────────┘
│
▼
タスク
（requires：
仕様、設計）
│
▼
┌──────────────┐
│ 実装フェーズ │
│（requires： │
│ タスク） │
└──────────────┘
状態遷移：
ブロック ────────────────► 準備完了 ────────────────► 完了
│ │ │
依存関係 すべての依存 ファイルがファイル
がない が完了 システムに存在
情報フロー
レガシーワークフロー — エージェントが静的指示を受け取ります：
ユーザー： "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ 静的指示： │
│ • proposal.md を作成 │
│ • tasks.md を作成 │
│ • design.md を作成 │
│ • specs/<capability>/spec.md を作成 │
│ │
│ 何が存在し、成果物の依存関係を │
│ 意識していません │
└─────────────────────────────────────────┘
│
▼
エージェントがすべての成果物を一度に作成します
OPSX — エージェントが豊富なコンテキストをクエリします：
ユーザー： "/rasen:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ ステップ 1：現在の状態をクエリ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ rasen status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── 最初に準備完了 │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ステップ 2：準備完了成果物の豊富な指示を取得 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ rasen instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ステップ 3：依存関係を読む → 1 つの成果物を作成 → ロック解除を表示 │
└──────────────────────────────────────────────────────────────────────────┘
イテレーションモデル
レガシーワークフロー — イテレーションが難しい：
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── 「待て、設計が間違っている」
│ │
│ ├── オプション：
│ │ • ファイルを手動で編集（コンテキストを破る）
│ │ • 放棄して最初から開始
│ │ • プッシュスルーして後で修正
│ │
│ └── 「戻る」メカニズムはありません
│
└── すべての成果物を一度に作成
OPSX — 自然なイテレーション：
/rasen:new ───► /rasen:continue ───► /rasen:apply ───► /rasen:archive
│ │ │
│ │ ├── 「設計が間違っている」
│ │ │
│ │ ▼
│ │ design.md を編集してください
│ │ そして続けてください！
│ │ │
│ │ ▼
│ │ /rasen:apply が拾い上げる
│ │ 停止したところから
│ │
│ └── 1 つの成果物を作成し、ロック解除を表示
│
└── スキャフォール変更、方向を待つ
カスタムスキーマ
スキーマ管理コマンドを使用してカスタムワークフローを作成します：
# 最初から新しいスキーマを作成（インタラクティブ）
rasen schema init my-workflow
# または既存スキーマを出発点として fork
rasen schema fork spec-driven my-workflow
# スキーマ構造を検証
rasen schema validate my-workflow
# スキーマがどこから解決されるかを確認（デバッグに便利）
rasen schema which my-workflow
スキーマは rasen/schemas/（プロジェクトローカル、バージョン管理）または ~/.rasen/schemas/（ユーザーグローバル；RASEN_HOME で場所をオーバーライド）に格納されます。
スキーマ構造：
rasen/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.md
example schema.yaml：
name: research-first
artifacts:
- id: research # 提案の前に追加
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # 現在、リサーチに依存
- id: tasks
generates: tasks.md
requires: [proposal]
依存関係グラフ：
research ──► proposal ──► tasks
要約
| 側面 | レガシー | OPSX |
|---|---|---|
| テンプレート | ハードコード TypeScript | 外部 YAML + Markdown |
| 依存関係 | なし（すべて一度に） | トポロジカルソート付き DAG |
| 状態 | フェーズベースのメンタルモデル | ファイルシステム存在 |
| カスタマイズ | ソースを編集、リビルド | schema.yaml を作成 |
| イテレーション | フェーズロック | 流動的、何でも編集 |
| エディターサポート | ツール固有のコンフィギュレーター/アダプター | 単一スキルディレクトリ |
スキーマ
スキーマは、どの成果物が存在し、それらの依存関係を定義します。現在利用可能：
- spec-driven（デフォルト）：提案 → 仕様 → 設計 → タスク
# 利用可能なスキーマをリスト
rasen schemas
# 解決ソースを含むすべてのスキーマを確認
rasen schema which --all
# 新しいスキーマをインタラクティブに作成
rasen schema init my-workflow
# カスタマイズのために既存スキーマを fork
rasen schema fork spec-driven my-workflow
# 使用前にスキーマ構造を検証
rasen schema validate my-workflow
ヒント
- アイデアを変更にコミットする前に
/rasen:exploreを使用して考え抜きます - 何をしたいかわかっている場合は
/rasen:ffを使用、探索している場合は/rasen:continueを使用します /rasen:apply中に問題があったら — 成果物を修正して続行します- タスクは
tasks.mdのチェックボックスを介して進行を追跡します - いつでも状態を確認：
rasen status --change "name"
フィードバック
これはラフです。それは意図的です — 私たちは何が最も良く機能するかを学んでいます。