概要
OpenSpec は AI コーディングワークフローに軽量な仕様レイヤーを追加し、人間と AI がコードを記述する前に要件を確実に一致させます。20+ 種類の AI アシスタント向けのスラッシュコマンドを提供し、機能ごとに変更を整理します。
README プレビュー
\n \n \n \n \n \n \n\n\n\n \n \n \n \n\n\n\nThe most loved spec framework.\n\n[](https://github.com/Fission-AI/OpenSpec/stargazers)\n[](https://www.npmjs.com/package/@fission-ai/openspec)\n[](https://github.com/Fission-AI/OpenSpec/graphs/contributors)\n\n\n\nOur philosophy:\n\n```text\n→ fluid not rigid\n→ iterative not waterfall\n→ easy not complex\n→ built for brownfield not just greenfield\n→ scalable from personal projects to enterprises\n```\n\n> [!TIP]\n> **New workflow now available!** We've rebuilt OpenSpec with a new artifact-guided workflow.\n>\n> Run `/opsx:propose "your idea"` to get started. → [Learn more here](docs/opsx.md)\n\n\n Follow @0xTab on X for updates · Join the OpenSpec Discord for help and questions.\n\n\n\n\n## See it in action\n\n```text\nYou: /opsx:explore\nAI: What would you like to explore?\nYou: I want dark mode but I'm not sure how to do it cleanly.\nAI: Let me look at your styling setup...\n Cleanest path here: CSS variables + a small theme context,\n with system-preference detection. No new dependencies. Scope it?\nYou: Yes, let's do it.\n\nYou: /opsx:propose add-dark-mode\nAI: Created openspec/changes/add-dark-mode/\n ✓ proposal.md — why we're doing this, what's changing\n ✓ specs/ — requirements and scenarios\n ✓ design.md — technical approach\n ✓ tasks.md — implementation checklist\n Ready for implementation!\n\nYou: /opsx:apply\nAI: Implementing tasks...\n ✓ 1.1 Add theme context provider\n ✓ 1.2 Create toggle component\n ✓ 2.1 Add CSS variables\n ✓ 2.2 Wire up localStorage\n All tasks complete!\n\nYou: /opsx:archive\nAI: Archived to openspec/changes/archive/2025-01-23-add-dark-mode/\n Specs updated. Ready for the next feature.\n```\n\n\nOpenSpec Dashboard\n\n\n \n\n\n\n\n## Quick Start\n\n**Requires Node.js 20.19.0 or higher.**\n\nInstall OpenSpec globally:\n\n```bash\nnpm install -g @fission-ai/openspec@latest\n```\n\nThen navigate to
FAQ (5)
ハウツーNode.js なしで OpenSpec をインストールする方法（スタンドアロンバイナリ）
v1.15.0 以降、OpenSpec は Node.js を必要としないスタンドアロンバイナリを提供しています。以下の方法でインストールしてください:
macOS / Linux:
curl -fsSL https://raw.githubusercontent.com/Fission-AI/OpenSpec/main/scripts/binary/install.sh | shWindows (PowerShell):
irm https://raw.githubusercontent.com/Fission-AI/OpenSpec/main/scripts/binary/install.ps1 | iex以前に npm 経由でインストールした場合は、openspec install を実行してスタンドアロンバイナリ版に切り替えてください。詳細は、リポジトリの docs/installation.md にあるインストールガイドを参照してください。
トラブル対応なぜ `openspec validate --strict` は要件が500文字を超えていてもパスするのですか？また、CIでこの制限を強制するにはどうすればよいですか？
OpenSpec **1.14.1 以降**にアップグレードしてください。以前は、overlong-requirement の検出は INFO として報告されていたため、openspec validate --all --strict はステータス 0 で終了していました。1.14.1 以降では、要件の説明が **500 文字**を超えると strict バリデーションが失敗します。次のコマンドで品質ゲートを実行してください：
openspec validate --all --strict既存の検出を修正するには、意味を変えずに長い要件を複数の小さな要件に分割してください。単に切り詰めてはいけません。また、エージェントのオーサリング手順にも 500 文字制限が明記され、新たに長すぎる要件が生じるのを防ぐようになっています。
トラブル対応openspec view でアーカイブされた変更を非表示にして、アクティブな変更が表示されたままになるようにするにはどうすればよいですか？
これは、openspec view ダッシュボードにアーカイブされた変更を追加した PR #399 で導入されたリグレッションです。この問題は PR fix(view): keep archived changes off the dashboard（issue #2030 をクローズ）で修正されました。その修正を含むリリースに OpenSpec をアップグレードし、openspec view を再度実行してください。アーカイブされた変更がアクティブな作業を画面から押し出すことがなくなります。一時的な回避策としては、openspec list を使用してください。
トラブル対応allowedEditRoots が宣言元のリポジトリと競合し、OpenSpec apply スキルがストアベースの変更を拒否する問題を修正する方法
OpenSpec 1.13.1 では、openspec status --change <name> --json --store plans が actionContext.allowedEditRoots を誤ってストアルート（/path/to/plans など）のみに設定することがあります。実装の編集は宣言元リポジトリ（/path/to/app など）で行う必要があるにもかかわらずです。生成された apply skill は、リポジトリコンテキストが CLI 管理の値と競合しているとみなし、0/N タスクで停止します。
修正方法：PR fix(status): include the declaring repo in store-backed edit roots を含む OpenSpec リリースにアップグレードしてください（またはコミット 0d814f39 以降からビルドしてください）。修正後、以下で確認します：
openspec status --change <name> --json --store plansactionContext.allowedEditRoots には両方のルートが含まれている必要があります：
["/path/to/app", "/path/to/plans"]ストアルートは計画アーティファクトを保持し、宣言元リポジトリのルートは実装の編集を保持します。mode と出力コントラクトは変更されません。
一時的な回避策：エージェントの拒否を手動でオーバーライドし、宣言元リポジトリとストアルートの両方での編集を明示的に許可します。その際、バグのある status 出力の allowedEditRoots が計画アーティファクトに限定されないことを明確にしてください。
トラブル対応「Archive the change」タスクと「Verify archived result」タスクがアーカイブをブロックする場合に、OpenSpecの循環依存を修正するにはどうすればよいですか？
OpenSpec 1.14.1+ にアップグレードしてください。このバージョンでは、openspec instructions apply は変更がアーカイブ可能であると宣言する代わりに、追跡対象タスクの完了のみを報告します。tasks.md では、アーカイブ前に完了できる作業のみを - [ ] チェックボックスとして残してください。アーカイブに依存するステップは、タスク数に影響しないように、通常の箇条書きセクションに移動してください：
## Workflow follow-up
- Archive the change after the project's review requirements are satisfied.
- Verify the archived result.完了メッセージは次のように変わります：「All tracked tasks are complete. Review or verify the change as appropriate before archiving.」state: "all_done"、タスクの解析、バリデーション、アーカイブの動作、およびフラグに変更はありません。古い標準版 OpenSpec では、警告を確認するか --yes を使用できます。未完了タスクがゼロであることを必須とする、より厳格なカスタムポリシーは、ポリシーを更新するか、アーカイブに依存するタスクを追跡対象リストから外す必要があります。