仕様モードに対応する Chorus プラグインは、提案をどの形式で作成するか（**仕様モード**）を自動的に決定します。OpenSpec モードは 3 つの仕様モードの 1 つで、作業中のリポジトリで OpenSpec が使えるときは常に既定になります。このモードでも [AI-DLC ワークフロー](/ja/guides/ai-dlc-workflow/)はいつも通りに動きますが、自由形式の Markdown を Chorus に直接打ち込むのではなく、エージェントが [`openspec`](https://github.com/Fission-AI/OpenSpec) CLI でディスク上に構造化ファイルを書き、それらを 提案の文書ドラフトへミラーします。ディスク上のファイルが作業コピーで、Chorus のドラフトはレビュー担当者が 提案ページで読む忠実なミラーです。 ## 3 つの仕様モード | モード | エージェントが書くもの | どんなときに選ばれるか | | --- | --- | --- | | `openspec` | `openspec/changes//` 下の構造化ファイル。ドラフトへミラーされる | OpenSpec が使えるときの既定 | | `lite` | `.chorus/specs//` 下の [Chorus 独自の軽量仕様](/ja/guides/spec-lite-mode/) | OpenSpec が使えないときの既定 | | `off` | 自由形式のドラフト。ローカルの仕様ファイルは一切書かない | 明示的に指定したときだけ | 仕様モードに対応する 6 つのプラグインは同じ解決規則を使いますが、解決のタイミングと確認方法が異なります。 | 実行環境 | 解決時点と確認方法 | | --- | --- | | Claude Code、Codex、Kiro、Pi | セッション開始時（Kiro はエージェント起動時）に解決し、注入された `## Spec Mode` コンテキストに結果を記載します。 | | dsh | プラグインの読み込み時に解決し、最初のエージェントステップで `## Spec Mode` を注入します。 | | OpenClaw | ステージスキルの仕様モード手順に到達した時点で同梱リゾルバーを実行します。セッション開始時に仕様モードのコンテキストは追加されません。`/chorus spec` または `/chorus status` で確認できます。 | 例えば OpenSpec と解決された場合は `CHORUS_SPEC_MODE=openspec` と表示されます。 接続の通知が表示されたかどうかでモードを推測しないでください。 ## モードの決まり方 優先順位の高い順に次のとおりです。 1. **明示的な `CHORUS_SPEC_MODE` が最優先。** `openspec`、`lite`、`off` のいずれかを設定すれば、 シェル単位・リポジトリ単位・CI ジョブ単位でモードを固定できます。 2. **設定がなければ、OpenSpec が使えるときは OpenSpec が既定。** 使えるとは次の 3 つがすべて成立することです。 リポジトリのルートに `openspec/` ディレクトリがある（`openspec init` が作成）、`openspec` CLI が `PATH` にある、そして OpenSpec が無効化されていない（[別のモードを選ぶ](#別のモードを選ぶ)を参照）。 3. **それ以外は `lite`。** Chorus 独自のフォールバックで、何もインストールせずに使えます。 OpenSpec が使えない場所で `CHORUS_SPEC_MODE=openspec` を固定した場合、要求したモードを使えないことをセッションが報告し、 ワークフローは黙って別の形式で作成を進めるのではなく**停止**します。 原因を解消する（CLI をインストールする、`openspec init` を実行する、OpenSpec を再度有効にする）か、 使えるモードを選んでください。指定したモードが自動的に別のモードへ切り替わることはありません。 認識できない `CHORUS_SPEC_MODE` の値は未設定として扱い、その理由を表示します。上記 3 つの正確な値を 使ってください。スタンドアロンのスキル配布物には仕様モードのルーティングがなく、引き続き自由形式の文書を書きます。 ## インストールと初期化 OpenSpec は Fission AI 製の Node CLI です。まずグローバルにインストールし、次にエージェントが提案を作成する リポジトリで初期化します。 ```bash npm install -g @fission-ai/openspec openspec init ``` `openspec init` は `openspec/` 作業ディレクトリ（`changes/`、`specs/`、設定と説明ファイル）を作成します。 開始時に解決する環境ではセッションを再起動し、dsh ではプラグインを再読み込みしてください。OpenClaw は次の 仕様モード手順で再解決します。解決するプロセスから `openspec/` ディレクトリと CLI の両方が見える必要があります。 プラグインのインストールは[エージェントプラットフォーム](/ja/reference/agents/)を参照してください。 ## proposal、develop、yolo での変化 モードが有効な間、proposal、develop、yolo の各スキルは kebab-case のスラッグでディスク上に変更を作成し、 3 種類のファイルを Chorus 提案の文書ドラフトへミラーします。 - **PRD**：`openspec/changes//proposal.md` - **技術設計**：`openspec/changes//design.md` - **仕様（能力ごとに 1 つ）**：`openspec/changes//specs//spec.md` `openspec/changes//tasks.md` は**ミラーされません**。Chorus の課題ドラフトが課題の唯一の正本で あるため、OpenSpec の課題リストはディスク上に残されます。 後の実行が変更を復元できるよう、提案の説明には正確な 1 行が付きます。 ```text OpenSpec change slug: ``` ミラーはバイト単位で元のファイルと同一です。プラグインは各ファイルのバイト列をそのままドラフトへ流し込み、モデルに内容を 打ち直させないため、ローカルファイルと Chorus ドラフトは同一に保たれます。これを自分で実行することは ありません。プラグインのスキルが、ネイティブ MCP クライアント `chorus mcp call --arg-file content=` を使って処理し、`chorus` CLI が `PATH` にないときにのみ、従来の `chorus-api.sh` / `chorus-mcp-call.sh` ラッパーにフォールバックします。厳密な仕様（エラー時の停止ルールと承認後の再同期）は、プラグインのスキル定義に 記載されています。 ## `openspec archive` を実行するタイミング `openspec archive` は変更の一番最後まで先送りされます。変更の**最後の**課題が検証された後、エージェントは 実行環境のフック通知またはスキルの手順に従って実行します。 ```bash openspec archive ``` アーカイブは変更を `openspec/changes/` から移し、その仕様デルタを `openspec/specs/` 下の長期仕様へ マージします。その後プラグインは、更新された `openspec/specs//spec.md` ファイルを、対応する Chorus 文書へ逆方向にミラーします。それまでは変更は進行中のままで、Chorus はデルタ仕様しか目にしないため、 半端にマージされた状態を考える必要はありません。 ## 別のモードを選ぶ 切り替え方法は 3 つあり、優先順位の高い順に次のとおりです。 1. **`CHORUS_SPEC_MODE`**（すべての実行環境）。避けたいものを述べるのではなく、欲しいモードを直接 名指しする最も素直な指定方法です。 ```bash export CHORUS_SPEC_MODE=lite # Chorus 独自のローカル仕様 export CHORUS_SPEC_MODE=off # 自由形式。ローカルの仕様ファイルなし ``` 2. **`enableOpenSpec` userConfig トグル**（Claude Code プラグインのみ、既定でオン）。プラグインの インストール設定でこれをオフにすると、アーカイブのリマインダーを含め、プラグイン全体で OpenSpec を 使えない状態にできます。 3. **`CHORUS_OPENSPEC_MODE=off` 環境変数**（すべての実行環境）。シェル単位で効く従来からの OpenSpec オプトアウトで、現在も有効です。 ```bash export CHORUS_OPENSPEC_MODE=off ``` 後の 2 つは OpenSpec を*使えない*状態にするだけなので、セッションは 自由形式ではなく `lite` に落ち着きます。ローカルの仕様ファイルを一切作りたくないなら、明示的に `off` を 指定してください。いずれの場合も、ディスク上の既存の `openspec/` ディレクトリはそのまま残され、新しい 提案に OpenSpec のスラッグ行が加わることもありません。 ## エージェント向け - **トリガー。** proposal、develop、yolo は実行環境が解決した `CHORUS_SPEC_MODE` を使います。 `## Spec Mode` が注入されていればそれを読みます。OpenClaw は仕様モード手順ごとに同梱リゾルバーを 実行します。他の環境で注入がない場合は、そのスキルの代替手順に従ってください。文章から解決規則を 自作してはいけません。`CHORUS_OPENSPEC_ACTIVE=1` は OpenSpec が使用可能であることを示します。モードが `lite` なら spec-lite に従い、`off` ならインラインで作成します。明示的な `openspec` を満たせない場合は**停止**し、フォールバックしません。 最後の課題の検証後は、実行環境のフックまたはスキルに従って `openspec archive ` を実行します。 すべての環境に PostToolUse があるとは仮定しないでください。 - **制約。** 文書ドラフトのミラー呼び出しはすべて、`chorus mcp call '' --arg-file content=` （ネイティブ MCP クライアント）を通し、ファイルのバイト列をそのままストリームする必要があります。 `chorus` が `PATH` にないときにのみ、従来の `chorus-api.sh mcp-tool` / `chorus-mcp-call.sh` ラッパーに フォールバックします。文書の内容を決してインラインで打ち直さず、エラーがあれば停止します。 `tasks.md` はミラーしないでください。提案の説明には正確な `OpenSpec change slug: ` の 1 行を 付ける必要があります。モードが `openspec` でないときは、`openspec/changes/` をスキャフォールドせず、 スラッグ行も加えないでください。スタンドアロンのスキル配布物は仕様モードをサポートしません。