Spec-lite モード

Spec-lite は Chorus 独自の軽量な仕様モードです。git で追跡される小さな仕様の記録で、何もインストールする必要がありません。リポジトリで OpenSpec が使えないときにセッションが使うモードであり、CHORUS_SPEC_MODE=lite で明示的に要求したときにも選ばれます。OpenSpec の経路と比べて意図的に小さく、CLI も検証ステップもアーカイブステップもデルタ文法もありません。そのため時間とトークンの消費が少なく、それでも git log で読める記録が残ります。

AI-DLC ワークフローは変わりません。変わるのはローカルの仕様ファイルの形だけです。

いつ選ばれるか

実行環境の仕様モードの結果が CHORUS_SPEC_MODE=lite か確認してください。Claude Code、Codex、Kiro、Pi は開始時のコンテキスト、dsh はプラグイン読み込み後の最初のエージェントステップで報告します。OpenClaw は開始時に注入せず、ステージスキルの実行時に解決します。/chorus spec または /chorus status で確認できます。

lite になる理由は 2 つあります。このリポジトリで OpenSpec が使えない場合（openspec/ ディレクトリと openspec CLI を必要とするため、こちらが一般的です）、または自分で要求した場合です。

export CHORUS_SPEC_MODE=lite

こう固定すると、OpenSpec が動くリポジトリでも spec-lite になります。優先順位の全体はモードの決まり方を参照してください。

ディスクに残るもの

すべて .chorus/specs/ の下にあり、.chorus/ のうちコミットすることを想定しているのはこの部分だけです。

.chorus/specs/<capability-slug>/
├── spec.md                              # 継続的。同期されない
└── 2026-09-08-add-csv-export/           # 変更の取り組みごとに 1 フォルダ
    ├── prd.md                           # → Chorus の PRD 文書
    └── tech_design.md                   # → Chorus の技術設計文書

継続的な仕様 <capability-slug>/spec.md。 能力や機能ごとに 1 つで、変更ごとではありません。意図、受け入れ観点付きの要件、非目標をまとめた累積的な「現在の真実」です。どの変更もこれをその場で編集し、git の履歴がそのまま記録になります。変更履歴のセクションを維持する必要はありません。Chorus へコピーされることはなく、Chorus の識別子も持ちません。status（draft、active、done）は能力そのものを表します。変更が進行中なら active、デリバリー後に未完了の変更がなくなれば done、新しい変更が再び開きます。

変更ごとに 1 つの日付付きフォルダ <capability-slug>/<YYYY-MM-DD>-<change-slug>/。 日付で時系列に並びます。同日の異なる変更には異なる 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 行が付きます。

Spec-lite: .chorus/specs/<capability-slug>/<YYYY-MM-DD>-<change-slug>/

ローカルファイルからドラフト、そして文書へ

エージェントは段階的に同期します。

承認前：各変更文書の frontmatter に proposalUuid を記入し、documentUuid は空欄にします。提案の文書ドラフトにミラーし、その後の編集も同じドラフトを更新します。
承認時：ドラフトは永続文書になります。(proposalUuid, type) で特定し、ローカルに documentUuid を記録してもう一度ミラーします。これで Chorus 側の内容にも識別子が含まれます。
承認後：ローカルファイルを編集し、documentUuid で同じ文書を更新します。更新ごとにバージョンが上がります。能力レベルの継続的な spec.md はこの処理に入りません。

検索結果が 0 件または複数なら同期を停止して調べます。代替文書を作成したり、タイトルから推測したりしてはいけません。これはエージェントによるミラーであり、バックグラウンドのファイル監視ではありません。文書を読むと frontmatter はメタデータカードとして表示されます。

`spec.md` という名前の 2 つのファイル

<capability-slug>/spec.md は継続的なほうで、ローカル限定、Chorus の識別子を持ちません。 <capability-slug>/<日付付きフォルダ>/spec.md にあるものは別物で、Chorus へ同期される変更範囲の仕様文書です。変更の主文書として prd.md を選んでおけば、この曖昧さに出会うことはありません。

変更が進行している間

進行中の変更の日付付きフォルダは編集し続けられます。作業が入るたびにエージェントはそのフォルダと継続的な spec.md の両方を更新し、変更文書を再ミラーし、受け入れ観点にチェックを入れます。すでにデリバリー済みの変更のフォルダには手を付けません。新しい変更は新しい日付付きフォルダで、過去のものを書き換えることはありません。

複数の課題が並行して進むときは、これらのファイルに書き込むのはメインのエージェントだけで、ワーカーは Chorus 経由で進捗を報告します。こうすることで、共有フォルダが 2 つのセッションから同時に上書きされることを防げます。

対応している実行環境

Spec-lite は Chorus プラグインとともに Claude Code、Codex、Kiro、Pi、OpenClaw、dsh で提供されます。モードの規則は共通ですが、開始の仕組みは異なります。OpenSpec ガイドを参照してください。スタンドアロンのスキル配布物には仕様モードのルーティングがなく、引き続き自由形式で編集します。

エージェント向け

トリガー。 実行環境の解決結果が CHORUS_SPEC_MODE=lite の場合だけ spec-lite を使います。注入された ## Spec Mode があれば読みます。OpenClaw はステージスキルの仕様モード手順で同梱リゾルバーを実行します。他の環境でコンテキストがない場合は、そのスキルの代替手順に従い、検出規則を自作しないでください。他のモードではこのスキルは何もしません。
制約。 継続的な <slug>/spec.md を決してミラーしないでください。日付付きフォルダの文書は chorus mcp call <tool> '<json>' --arg-file content=<file> でミラーし、本文を打ち直すのではなくファイルからストリームします。chorus が PATH にないときにのみ chorus-api.sh / chorus-mcp-call.sh ラッパーにフォールバックします。文書の同一性は documentUuid または (proposalUuid, type) で解決し、該当が 0 件または 2 件以上なら停止します。タイトルだけで一致させてはなりません。ミラーでエラーが出たら停止します。tasks.md を作らず、 openspec/changes/ もスキャフォールドしないでください。提案の説明には正確な Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/ の位置指定行を、独立した 1 行として末尾に句読点なしで付ける必要があります。
出典。 public/chorus-plugin/skills/spec-lite/SKILL.md（権威あるスキル。2 つの開始用テンプレートをファイル内に掲載）と public/chorus-plugin/bin/resolve-spec-mode.sh（モード解決の単一の真実の源）。