Spec-lite は Chorus 独自の軽量な仕様モードです。git で追跡される小さな仕様の記録で、何もインストール する必要がありません。リポジトリで [OpenSpec](/ja/guides/openspec-mode/) が使えないときにセッションが 使うモードであり、`CHORUS_SPEC_MODE=lite` で明示的に要求したときにも選ばれます。OpenSpec の経路と 比べて意図的に小さく、CLI も検証ステップもアーカイブステップもデルタ文法もありません。そのため時間と トークンの消費が少なく、それでも `git log` で読める記録が残ります。 [AI-DLC ワークフロー](/ja/guides/ai-dlc-workflow/)は変わりません。変わるのはローカルの仕様ファイルの 形だけです。 ## いつ選ばれるか 実行環境の仕様モードの結果が `CHORUS_SPEC_MODE=lite` か確認してください。Claude Code、Codex、Kiro、Pi は 開始時のコンテキストで、DeepSeek Harness（`dsh`）はプラグイン読み込み後の最初のエージェントステップで報告します。OpenClaw は開始時に 注入せず、ステージスキルの実行時に解決します。`/chorus spec` または `/chorus status` で確認できます。 `lite` になる理由は 2 つあります。このリポジトリで OpenSpec が使えない場合（`openspec/` ディレクトリと `openspec` CLI を必要とするため、こちらが一般的です）、または自分で要求した場合です。 ```bash export CHORUS_SPEC_MODE=lite ``` こう固定すると、OpenSpec が動くリポジトリでも spec-lite になります。優先順位の全体は [モードの決まり方](/ja/guides/openspec-mode/#モードの決まり方)を参照してください。 ## ディスクに残るもの すべて `.chorus/specs/` の下にあり、`.chorus/` のうちコミットすることを想定しているのはこの部分だけです。 ```text .chorus/specs// ├── spec.md # 継続的。同期されない └── 2026-09-08-add-csv-export/ # 変更の取り組みごとに 1 フォルダ ├── prd.md # → Chorus の PRD 文書 └── tech_design.md # → Chorus の技術設計文書 ``` **継続的な仕様 `/spec.md`。** 能力や機能ごとに 1 つで、変更ごとでは*ありません*。 意図、受け入れ観点付きの要件、非目標をまとめた累積的な「現在の正となる仕様」です。どの変更もこれをその場で 編集し、git の履歴がそのまま記録になります。変更履歴のセクションを維持する必要はありません。Chorus へ コピーされることは**なく**、Chorus の識別子も持ちません。`status`（`draft`、`active`、`done`）は能力 そのものを表します。変更が進行中なら `active`、デリバリー後に未完了の変更がなくなれば `done` になり、新しい変更が始まると再び `active` に戻ります。 **変更ごとに 1 つの日付付きフォルダ `/-/`。** フォルダは日付で時系列に 並びます。同日の異なる変更には異なる change slug を使ってください。中の各ファイルが Chorus の文書タイプ 1 つに対応し、 `prd.md` は必須、`tech_design.md`、`adr.md`、`guide.md`、あるいは変更範囲の `spec.md` は必要なときだけ 加えます。これらのファイルは Chorus へ**ミラーされます**。1 ファイルが 1 つの永続文書に対応し、モデルが 打ち直すのではなくファイルの内容がそのまま書き込まれるため、ローカルファイルと Chorus 文書は同一に保たれます。 承認後の編集をミラーするたびにその文書のバージョンが上がり、それが git と並ぶ Chorus 側の記録になります。 `tasks.md` はありません。課題は課題ドラフトとして Chorus に存在し、`spec.md` の受け入れ観点は意図の 表明であって進捗トラッカーではありません。 後のセッションが変更を見つけられるよう、提案の説明には正確な 1 行が付きます。 ```text Spec-lite: .chorus/specs//-/ ``` ## ローカルファイルからドラフト、そして文書へ エージェントは段階的に同期します。 1. **承認前**：各変更文書の frontmatter に `proposalUuid` を記入し、`documentUuid` は空欄にします。 提案の文書ドラフトにミラーし、その後の編集も同じドラフトを更新します。 2. **承認時**：ドラフトは永続文書になります。`(proposalUuid, type)` で特定し、ローカルに `documentUuid` を記録してもう一度ミラーします。これで Chorus 側の内容にも識別子が含まれます。 3. **承認後**：ローカルファイルを編集し、`documentUuid` で同じ文書を更新します。更新ごとにバージョンが 上がります。能力レベルの継続的な `spec.md` はこの処理に入りません。 検索結果が 0 件または複数なら同期を停止して調べます。代替文書を作成したり、タイトルから推測したりしては いけません。これはエージェントによるミラーであり、バックグラウンドのファイル監視ではありません。文書を読むと frontmatter は[メタデータカード](/ja/guides/documents/#文書の先頭のメタデータ)として表示されます。 ## `spec.md` という名前の 2 つのファイル `/spec.md` は継続的なほうで、ローカル限定、Chorus の識別子を持ちません。 `/<日付付きフォルダ>/spec.md` にあるものは別物で、Chorus へ*同期される*変更範囲の 仕様文書です。変更の主文書として `prd.md` を選んでおけば、この曖昧さに出会うことはありません。 ## 変更が進行している間 進行中の変更の日付付きフォルダは編集し続けられます。作業が入るたびにエージェントはそのフォルダと 継続的な `spec.md` の両方を更新し、変更文書を再ミラーし、受け入れ観点にチェックを入れます。**すでに デリバリー済み**の変更のフォルダには手を付けません。新しい変更は新しい日付付きフォルダで、過去のものを 書き換えることはありません。 複数の課題が並行して進むときは、これらのファイルに書き込むのはメインのエージェントだけで、ワーカーは Chorus 経由で進捗を報告します。こうすることで、共有フォルダが 2 つのセッションから同時に上書きされる ことを防げます。 ## 対応している実行環境 Spec-lite は Chorus プラグインとともに Claude Code、Codex、Kiro、Pi、OpenClaw、dsh で提供されます。 モードの規則は共通ですが、開始の仕組みは異なります。[OpenSpec ガイド](/ja/guides/openspec-mode/)を 参照してください。スタンドアロンのスキル配布物には仕様モードのルーティングがなく、引き続き自由形式の文書を書きます。 ## エージェント向け - **トリガー。** 実行環境の解決結果が `CHORUS_SPEC_MODE=lite` の場合だけ spec-lite を使います。 注入された `## Spec Mode` があれば読みます。OpenClaw はステージスキルの仕様モード手順で同梱リゾルバーを 実行します。他の環境でコンテキストがない場合は、そのスキルの代替手順に従い、検出規則を自作しないでください。 他のモードではこのスキルは何もしません。 - **制約。** 継続的な `/spec.md` を決してミラーしないでください。日付付きフォルダの文書は `chorus mcp call '' --arg-file content=` でミラーし、本文を打ち直すのではなく ファイルからストリームします。`chorus` が `PATH` にないときにのみ `chorus-api.sh` / `chorus-mcp-call.sh` ラッパーにフォールバックします。文書の同一性は `documentUuid` または `(proposalUuid, type)` で解決し、該当が 0 件または 2 件以上なら**停止**します。タイトルだけで 一致させてはなりません。ミラーでエラーが出たら停止します。`tasks.md` を作らず、 `openspec/changes/` もスキャフォールドしないでください。提案の説明には正確な `Spec-lite: .chorus/specs//-/` の位置指定行を、独立した 1 行として 末尾に句読点なしで付ける必要があります。