Fission-AI/OpenSpec

AI にコードを書かせるとき、「何を作るか」はたいていチャットの履歴の中だけにある。OpenSpec は、そこに仕様の層をひとつ足す道具で、コードが書かれる前に人間と AI が合意するところを作業の中心に置く。README はこれを「要件がチャット履歴の中にしか無い状態」への対処だと説明している。書かれている言語は TypeScript、ライセンスは MIT。

入れるのと更新するのは CLI（openspec init など）で、日々の入口はコーディング支援ツール側のスラッシュコマンドになる。/opsx:explore で何を作るか相談し、/opsx:propose で変更ひとつぶんのフォルダを作る。中には提案・要件・設計・タスクの4つが入る。要件はふつうの Markdown で書かれ、覚える独自の記法は無いと README は書いている。書き方は「〜する」という文と、「こうしたとき、こうなる」という場面の組になっている。そのまま /opsx:apply で実装し、/opsx:archive でその変更をしまうと、決まった内容が仕様の側に反映される。

コマンドの呼び名は使う道具によって綴りが変わり（/opsx-propose や @opsx-propose など）、初期化のときに自分の道具に合った形が表示される。README は対応を「30種類以上」と書いている。チーム向けには Stores という仕組みがあり、計画だけを別のリポジトリに置いて複数のリポジトリから参照する使い方ができる。ただしこちらはベータと明記されている。

決めたはずのことが、チャットの履歴に埋もれるとき

やり取りの中で決めた仕様は、会話を閉じた時点で追いにくくなる。OpenSpec は変更ごとにフォルダを切り、提案・要件・設計・タスクをファイルとして残す。リポジトリの中に置かれるので、次に開いた AI も同じものを読める。

複数のリポジトリにまたがる機能を、先に決めたいとき

API とアプリと共通部品に分かれている場合、計画だけを別リポジトリ（Stores）に置いて、各リポジトリから参照する形が取れる。README は「コードが3つのリポジトリに分かれても、計画はひとつ」と説明している。ただしベータ扱いなので、重要な案件でいきなり頼るのは早い。

Stores はまだベータ。 README 自身がそう書いている。チームで使う前提の機能なので、動かなくなったときの影響も人数ぶんになる。まずは1リポジトリでの使い方から始めるほうが安全だ。

枠が緩いぶん、進め方は自分で持つことになる。 OpenSpec は、工程ごとに関門を置くやり方（README は Spec Kit をその例に挙げている）と対比して、どの文書もいつでも直せることを利点として挙げている。裏を返せば、どこまで決まったかを管理するのは書き手の側だということでもある。

モデルと文脈の条件が付く。 README は推論の強いモデルを勧め、実装に入る前に文脈（コンテキスト）を空にしておくことを勧めている。手元の道具立てによって、同じようには動かない可能性がある。

匿名の利用統計が既定で送られる。 送るのはコマンド名と版だけで、引数やパスや中身は含まないと明記されている。設定か環境変数で止められる。動かすのに Node.js 20.19.0 以上が要る。ライセンスは MIT。