コマンド

これは OpenSpec のスラッシュコマンドのリファレンスです。これらのコマンドは、AI コーディングアシスタントのチャットインターフェース（例：Claude Code、Cursor、Devin Desktop）で呼び出されます。

ワークフローパターンや各コマンドの使用タイミングについては、Workflows を参照してください。CLI コマンドについては、CLI を参照してください。

これらのページでは、標準的な名前として /opsx:<command> を使用しています。一部のツールでは表記が異なる場合があります — Cursor や GitHub Copilot では /opsx-propose、Codex では $openspec-propose と登録されています — ので、お使いのツールについては How To Invoke をご確認ください。OpenSpec が生成するファイルには、すでに適切な形式が使用されています。

クイックリファレンス

デフォルトのクイックパス（`core` プロファイル）

コマンド	目的
`/opsx:propose`	変更を作成し、計画用アーティファクトを一度に生成する
`/opsx:explore`	変更を実施する前にアイデアを検討する
`/opsx:apply`	変更のタスクを実装する
`/opsx:update`	変更の計画用アーティファクトを更新し、整合性を保つ
`/opsx:sync`	デルタ仕様をメイン仕様に取り込む
`/opsx:archive`	完了した変更をアーカイブする

拡張ワークフローコマンド（カスタムワークフロー選択）

コマンド	目的
`/opsx:new`	新しい変更のスケルトンを作成する
`/opsx:continue`	依存関係に基づいて次のアーティファクトを作成する
`/opsx:ff`	ファストフォワード：すべての計画用アーティファクトを一度に作成する
`/opsx:verify`	実装がアーティファクトと一致していることを検証する
`/opsx:bulk-archive`	複数の変更を一度にアーカイブする
`/opsx:onboard`	ワークフロー全体を通じたガイド付きチュートリアル

デフォルトのグローバルプロファイルは core です。拡張ワークフローコマンドを有効にするには、openspec config profile を実行してワークフローを選択し、その後プロジェクト内で openspec update を実行します。

コマンドリファレンス

`/opsx:propose`

新しい変更を作成し、1ステップで計画成果物を生成します。これは core プロファイルのデフォルトの開始コマンドです。

構文:

text

/opsx:propose [change-name-or-description]

引数:

引数	必須	説明
`change-name-or-description`	いいえ	Kebab-case の名前または自然言語による変更の説明

実行内容:

openspec/changes/<change-name>/ を作成
実装前に必要な成果物を生成（spec-driven の場合: proposal, specs, design, tasks）
/opsx:apply に対応する準備が整うまで停止

例:

text

You: /opsx:propose add-dark-mode

AI:  Created openspec/changes/add-dark-mode/
     ✓ proposal.md
     ✓ specs/ui/spec.md
     ✓ design.md
     ✓ tasks.md
     Ready for implementation. Run /opsx:apply.

ヒント:

最速のエンドツーエンドのパスに使用
ステップバイステップの成果物制御が必要な場合は、拡張ワークフローを有効にして /opsx:new + /opsx:continue を使用

`/opsx:explore`

迷ったらここから始めましょう。 Explore はリスクのない思考パートナーです。コードベースを読み込み、選択肢を比較し、変更が存在する前に曖昧なアイデアを具体的な計画に磨き上げます。デフォルトプロファイルに同梱されています。完全なケースや追加の例については、Explore First ガイドを参照してください。

変更をコミットする前に、アイデアを検討し、問題を調査し、要件を明確にします。

構文:

/opsx:explore [topic]

引数:

引数	必須	説明
`topic`	いいえ	探索または調査したい内容

実行内容:

構造を必要としない探索的な対話を開始
質問に答えるためにコードベースを調査
選択肢やアプローチを比較
思考を明確にするための視覚的ダイアグラムを作成
洞察が結実した時点で /opsx:propose（デフォルト）または /opsx:new（拡張ワークフロー）に移行可能

例:

text

You: /opsx:explore

AI:  What would you like to explore?

You: How should we handle authentication for the mobile app?

AI:  Let me investigate your current auth setup...
     [Analyzes codebase]

     I see you're using session-based auth for the web app.
     For mobile, we have three main options:

     1. JWT tokens (stateless, works offline)
     2. OAuth2 (if you need third-party login)
     3. Extend current sessions (simpler, but requires connectivity)

     Your API already has CORS configured. Which direction interests you?

You: Let's go with JWT. Can we start a change for that?

AI:  Ready when you are. Run /opsx:propose add-jwt-auth to begin.

ヒント:

要件が不明確な場合や調査が必要な場合に使用
探索中は成果物は作成されません
決定前に複数のアプローチを比較するのに適しています
ファイルの読み取りやコードベースの検索が可能です

`/opsx:new`

新しい変更のスケルトンを作成します。変更フォルダを作成し、/opsx:continue または /opsx:ff で成果物を生成するのを待ちます。

このコマンドは拡張ワークフローセットの一部です（デフォルトの core プロファイルには含まれません）。

構文:

/opsx:new [change-name] [--schema <schema-name>]

引数:

引数	必須	説明
`change-name`	いいえ	変更フォルダの名前（未指定の場合はプロンプトで入力）
`--schema`	いいえ	使用するワークフロースキーマ（デフォルト: 設定または `spec-driven`）

実行内容:

openspec/changes/<change-name>/ ディレクトリを作成
変更フォルダ内に .openspec.yaml メタデータファイルを作成
作成準備ができた最初の成果物テンプレートを表示
未指定の場合は変更名とスキーマの入力をプロンプト

作成されるもの:

openspec/changes/<change-name>/
└── .openspec.yaml    # Change metadata (schema, created date)

例:

You: /opsx:new add-dark-mode

AI:  Created openspec/changes/add-dark-mode/
     Schema: spec-driven

     Ready to create: proposal
     Use /opsx:continue to create it, or /opsx:ff to create all artifacts.

ヒント:

説明的な名前を使用: add-feature, fix-bug, refactor-module
update, changes, wip のような汎用的な名前は避ける
スキーマはプロジェクト設定（openspec/config.yaml）でも設定可能

`/opsx:continue`

依存関係チェーンの次の成果物を作成します。成果物を1つずつ作成して段階的な進捗を実現します。

構文:

/opsx:continue [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	継続する変更（未指定の場合はコンテキストから推定）

実行内容:

成果物の依存関係グラフをクエリ
どの成果物が作成可能か、ブロックされているかを表示
作成可能な最初の成果物を作成
依存ファイルを読み込んでコンテキストを取得
作成後に利用可能になるものを表示

例:

You: /opsx:continue

AI:  Change: add-dark-mode

     Artifact status:
     ✓ proposal    (done)
     ◆ specs       (ready)
     ◆ design      (ready)
     ○ tasks       (blocked - needs: specs, design)

     Creating specs...

     [Reads proposal.md, creates specs based on requirements]

     ✓ Created openspec/changes/add-dark-mode/specs/ui/spec.md

     Now available: design
     Run /opsx:continue to create the next artifact.

ヒント:

各成果物をレビューしてから進みたい場合に使用
制御したい複雑な変更に適しています
複数の成果物が同時に作成可能になる場合があります
継続前に作成された成果物を編集できます

`/opsx:ff`

成果物の作成をフォワードします。すべての計画成果物を一度に作成します。

構文:

/opsx:ff [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	フォワードする変更（未指定の場合はコンテキストから推定）

実行内容:

依存関係の順序ですべての成果物を作成
Todo リストで進捗を追跡
すべての apply-required 成果物が完了するまで停止
次の成果物を作成する前に各依存を読み取り

例:

You: /opsx:ff add-dark-mode

AI:  Fast-forwarding add-dark-mode...

     ✓ Creating proposal.md
     ✓ Creating specs/ui/spec.md
     ✓ Creating design.md
     ✓ Creating tasks.md

     All planning artifacts complete!
     Ready for implementation. Run /opsx:apply to begin.

ヒント:

何を構築するか明確な場合に使用
単純な変更では /opsx:continue より高速
後で成果物を編集できます
小〜中規模の機能に適しています

`/opsx:apply`

変更からタスクを実装します。タスクリストに従ってコードを書き、項目にチェックを入れます。

構文:

/opsx:apply [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	実装する変更（未指定の場合はコンテキストから推定）

実行内容:

tasks.md を読み取り、未完了のタスクを特定
タスクを1つずつ処理
必要に応じてコードを書き、ファイルを作成、テストを実行
チェックボックス [x] でタスク完了をマーク

例:

You: /opsx:apply

AI:  Implementing add-dark-mode...

     Reading tasks.md:
     - [ ] 1.1 Create ThemeContext
     - [ ] 1.2 Add CSS custom properties
     - [ ] 1.3 Implement localStorage persistence

     Working on 1.1: Create ThemeContext...
     [Creates src/context/ThemeContext.tsx]

     ✓ 1.1 Complete

     Working on 1.2: Add CSS custom properties...
     [Updates src/styles/globals.css]

     ✓ 1.2 Complete
     ...

ヒント:

中断された場合、続きから再開できます
変更名を指定することで並行変更に対応
完了状態は tasks.md のチェックボックスで追跡されます

`/opsx:update`

変更の既存の計画成果物を修正し、それらが互いに整合性を保つようにします。計画成果物のみ対象で、コードは編集しません。

構文:

text

/opsx:update [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	更新する変更（未指定の場合はコンテキストから推定）

実行内容:

openspec status --change <name> --json で変更の成果物を読み取り
指定された修正を適用するか、指定がなければ成果物内の矛盾をレビュー
既存の他の成果物と両方向に調整（design の編集が proposal に波及する可能性あり）
書き込み前に1つの成果物ずつ確認
次のステップを推奨して終了: /opsx:continue（成果物不足）、/opsx:apply（修正後の計画をコードに反映）、または /opsx:archive（すべて完了）

例:

text

You: /opsx:update add-dark-mode - we're storing the theme in a cookie now, not localStorage

AI:  Reading add-dark-mode artifacts...

     The design references localStorage in two places; tasks 1.3 covers
     localStorage persistence; the proposal doesn't mention storage.

     Proposed revisions:
     1. design.md - swap localStorage decision for cookie storage
     2. tasks.md - reword task 1.3 to cookie persistence

     Apply revision 1? (design.md)

ヒント:

不足している成果物を作成しません - それには /opsx:continue を使用
変更がすでに実装済みの場合は、コードが修正後の計画と一致するように /opsx:apply でフォローアップ
修正が変更の意図を変える場合は、新しい変更として最初からやり直す（Update と最初からやり直しの判断基準を参照）

`/opsx:verify`

実装が変更の成果物と一致していることを検証します。完全性、正確性、整合性をチェックします。

構文:

/opsx:verify [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	検証する変更（未指定の場合はコンテキストから推定）

実行内容:

実装品質の3つの側面をチェック
実装の証拠をコードベースから検索
CRITICAL、WARNING、SUGGESTION に分類して問題を報告
アーカイブをブロックはしないが、問題を可視化

検証の側面:

側面	検証内容
完全性	すべてのタスク完了、すべての要件実装、シナリオ網羅
正確性	実装が仕様意図と一致、エッジケース対応
整合性	デザイン決定がコードに反映、パターン一貫性

例:

You: /opsx:verify

AI:  Verifying add-dark-mode...

     COMPLETENESS
     ✓ All 8 tasks in tasks.md are checked
     ✓ All requirements in specs have corresponding code
     ⚠ Scenario "System preference detection" has no test coverage

     CORRECTNESS
     ✓ Implementation matches spec intent
     ✓ Edge cases from scenarios are handled
     ✓ Error states match spec definitions

     COHERENCE
     ✓ Design decisions reflected in code structure
     ✓ Naming conventions consistent with design.md
     ⚠ Design mentions "CSS variables" but implementation uses Tailwind classes

     SUMMARY
     ─────────────────────────────
     Critical issues: 0
     Warnings: 2
     Ready to archive: Yes (with warnings)

     Recommendations:
     1. Add test for system preference detection
     2. Update design.md to reflect Tailwind usage, or refactor to use CSS variables

ヒント:

アーカイブ前に実行して、不一致を早期に検出
Warning はアーカイブをブロックしないが、潜在的問題を示します
コミット前に AI の作業をレビューするのに適しています
成果物と実装の間の乖離を明らかにできます

`/opsx:sync`

オプションコマンド。 変更のデルタ仕様をメイン仕様へマージします。アーカイブ時に必要に応じて同期をプロンプトするので、通常は手動で実行する必要はありません。

構文:

/opsx:sync [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	同期する変更（未指定の場合はコンテキストから推定）

実行内容:

変更フォルダからデルタ仕様を読み取り
ADDED/MODIFIED/REMOVED/RENAMED セクションを解析
変更をメインの openspec/specs/ ディレクトリにマージ
デルタに言及されていない既存コンテンツを保持
変更をアーカイブしない（アクティブなまま）

例:

text

You: /opsx:sync

AI:  Syncing add-dark-mode delta specs...

     Reading: openspec/changes/add-dark-mode/specs/ui/spec.md
     Target:  openspec/specs/ui/spec.md

     Changes to apply:
     ✓ ADDED: Theme Selection requirement (2 scenarios)
     ✓ ADDED: Accessibility requirement (1 scenario)

     Merging...
     ✓ openspec/specs/ui/spec.md updated

     Change remains active. Run /opsx:archive when ready to complete.

手動で使用するタイミング:

シナリオ	sync を使う?
長期にわたる変更で、アーカイブ前にメインに仕様を入れたい	はい
複数の並行変更が更新されたベース仕様を必要とする	はい
マージを個別にプレビュー/レビューしたい	はい
素早い変更で、そのままアーカイブに進む	いいえ（アーカイブが処理）

ヒント:

Sync はインテリジェントで、コピー＆ペーストではありません
既存の要件にシナリオを追加しても重複しません
Sync 後も変更はアクティブなまま（アーカイブされない）
ほとんどのユーザーは直接呼び出す必要はありません - 必要に応じてアーカイブがプロンプトします

`/opsx:archive`

完了した変更をアーカイブします。変更を確定し、アーカイブフォルダへ移動します。

構文:

/opsx:archive [change-name]

引数:

引数	必須	説明
`change-name`	いいえ	アーカイブする変更（未指定の場合はコンテキストから推定）

実行内容:

成果物の完了状態をチェック
タスクの完了状況をチェック（未完了の場合は警告）
未同期の場合はデルタ仕様の同期を提案
変更フォルダを openspec/changes/archive/YYYY-MM-DD-<name>/ へ移動
監査証跡としてすべての成果物を保持

例:

text

You: /opsx:archive

AI:  Archiving add-dark-mode...

     Artifact status:
     ✓ proposal.md exists
     ✓ specs/ exists
     ✓ design.md exists
     ✓ tasks.md exists (8/8 tasks complete)

     Delta specs: Not yet synced
     → Sync now? (recommended)

You: Yes

AI:  ✓ Synced specs to openspec/specs/ui/spec.md
     ✓ Moved to openspec/changes/archive/2025-01-24-add-dark-mode/

     Change archived successfully.

ヒント:

未完了タスクでアーカイブをブロックはしないが、警告します
デルタ仕様はアーカイブ時または事前に同期可能
アーカイブされた変更は履歴として保持されます
問題を検出するために先に /opsx:verify を使用

`/opsx:bulk-archive`

複数の完了した変更を一度にアーカイブします。変更間の仕様競合を処理します。

構文:

/opsx:bulk-archive [change-names...]

引数:

引数	必須	説明
`change-names`	いいえ	アーカイブする特定の変更（未指定の場合は選択プロンプト）

実行内容:

すべての完了した変更を一覧表示
アーカイブ前に各変更を検証
変更間の仕様競合を検出
実際に実装されている内容を確認して競合を解決
年代順にアーカイブ

例:

You: /opsx:bulk-archive

AI:  Found 3 completed changes:
     - add-dark-mode (8/8 tasks complete)
     - fix-login-bug (3/3 tasks complete)
     - update-footer (2/2 tasks complete)

     Checking for spec conflicts...
     ⚠ add-dark-mode and update-footer both touch specs/ui/

     Inspecting codebase to resolve...
     Both changes are implemented. Will merge in chronological order:
     1. add-dark-mode (created Jan 20)
     2. update-footer (created Jan 22)

     Archive all 3 changes?

You: Yes

AI:  ✓ Archived add-dark-mode
     ✓ Archived fix-login-bug
     ✓ Archived update-footer
     Specs merged: add-dark-mode → update-footer

ヒント:

並行作業ストリームに適しています
競合解決はエージェント的（コードベースを確認）
変更は作成順にアーカイブされます
仕様コンテンツを上書きする前にプロンプトします

`/opsx:onboard`

完全な OpenSpec ワークフローを通じたガイド付きオンボーディング。実際のコードベースを使用したインタラクティブなチュートリアルです。

構文:

/opsx:onboard

実行内容:

ナレーション付きで完全なワークフローサイクルを体験
実際の改善機会をコードベースからスキャン
実際の成果物を含む変更を作成
実際の実装作業を実行（小規模で安全な変更）
完了した変更をアーカイブ
各ステップをその場で説明

フェーズ:

ウェルカムとコードベース分析
改善機会の発見
変更の作成（/opsx:new）
Proposal の作成
Specs の作成
Design の作成
Tasks の作成
タスクの実装（/opsx:apply）
実装の検証
変更のアーカイブ
サマリーと次のステップ

例:

You: /opsx:onboard

AI:  Welcome to OpenSpec!

     I'll walk you through the complete workflow using your actual codebase.
     We'll find something small to improve, create a proper change for it,
     implement it, and archive it.

     Let me scan your codebase for opportunities...

     [Analyzes codebase]

     I found a few things we could work on:
     1. Add input validation to the contact form
     2. Improve error messages in the auth flow
     3. Add loading states to async buttons

     Which interests you? (or suggest something else)

ヒント:

ワークフローを学ぶ新規ユーザーに最適
トイ例ではなく実際のコードを使用
保持または破棄できる実際の変更を作成
完了までに 15〜30 分かかります

AI ツール別のコマンド構文

AI ツールによって、コマンド構文がわずかに異なります。お使いのツールに合った形式を使用してください：

ツールのコマンドファイル	構文の例	対応ツール
`.../commands/opsx/<id>.*`	`/opsx:propose`, `/opsx:apply`	Claude Code, Gemini CLI, Crush
`.../opsx-<id>.*`	`/opsx-propose`, `/opsx-apply`	Cursor, Devin Desktop, Copilot (IDE), Trae, Oh My Pi
なし — スキルのみ	`/openspec-propose`, `/openspec-apply-change`	CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, 共有 `.agents`
なし — Kimi Code	`/skill:openspec-propose`	Kimi Code
なし — Codex CLI	`$openspec-propose`	Codex

Devin Desktop と Devin Local の違い: .devin/workflows/opsx-*.md ファイルにより、Devin Desktop では /opsx-propose が利用できます。Devin Local にはワークフローがありません — OpenSpec が .devin/skills/ に書き込むスキルを使用してください。例：/openspec-propose。これらは両方のエージェントで動作します。

ツールを問わず意図は同じですが、コマンドの表示方法は統合方法によって異なります。呼び出し方法にサポート対象のすべてのツールを記載しています。この表には各形式の例のみを示しています。

注意: GitHub Copilot コマンド (.github/prompts/*.prompt.md) は IDE 拡張機能 (VS Code, JetBrains, Visual Studio) でのみ利用可能です。GitHub Copilot CLI では現在カスタムプロンプトファイルはサポートされていません — 詳細と回避策についてはサポート対象ツールを参照してください。

レガシーコマンド

これらのコマンドは旧来の「一括処理」ワークフローを使用します。引き続き動作しますが、OPSX コマンドの使用を推奨します。

コマンド	機能
`/openspec:proposal`	すべての成果物を一括作成（提案、仕様、設計、タスク）
`/openspec:apply`	変更を実装する
`/openspec:archive`	変更をアーカイブする

レガシーコマンドを使用する場面:

旧ワークフローを使用している既存プロジェクト
段階的な成果物作成が不要な単純な変更
全有無方式（オールオアナッシング）を好む場合

OPSX への移行: レガシー変更は OPSX コマンドで継続できます。成果物の構造は互換性があります。

トラブルシューティング

「Change not found」

コマンドが対象の変更を特定できませんでした。

解決策:

変更名を明示的に指定する: /opsx:apply add-dark-mode
変更フォルダが存在するか確認する: openspec list
正しいプロジェクトディレクトリにいるか確認する

「No artifacts ready」

すべての成果物が完了しているか、依存関係の欠落によりブロックされています。

解決策:

openspec status --change <name> を実行してブロック要因を確認する
必要な成果物が存在するか確認する
欠落している依存関係の成果物を先に作成する

「Schema not found」

指定されたスキーマが存在しません。

解決策:

利用可能なスキーマを一覧表示する: openspec schemas
スキーマ名のスペルを確認する
カスタムスキーマの場合は作成する: openspec schema init <name>

コマンドが認識されない

AI ツールが OpenSpec コマンドを認識できません。

解決策:

OpenSpec が初期化されているか確認する: openspec init
スキルを再生成する: openspec update
.claude/skills/ ディレクトリが存在するか確認する（Claude Code の場合）
新しいスキルを反映するために AI ツールを再起動する

成果物が正しく生成されない

AI が不完全または誤った成果物を作成します。

解決策:

openspec/config.yaml にプロジェクトのコンテキストを追加する
成果物ごとのルールを追加して具体的なガイダンスを提供する
変更の説明に詳細を追加する
より細かな制御のために /opsx:ff の代わりに /opsx:continue を使用する

次のステップ

ワークフロー - 一般的なパターンと各コマンドの使い分け
CLI - 管理と検証用のターミナルコマンド
カスタマイズ - カスタムスキーマとワークフローの作成

コマンド ​

クイックリファレンス ​

デフォルトのクイックパス（core プロファイル） ​

拡張ワークフローコマンド（カスタムワークフロー選択） ​

コマンドリファレンス ​

/opsx:propose ​

/opsx:explore ​

/opsx:new ​

/opsx:continue ​

/opsx:ff ​

/opsx:apply ​

/opsx:update ​

/opsx:verify ​

/opsx:sync ​

/opsx:archive ​

/opsx:bulk-archive ​

/opsx:onboard ​

AI ツール別のコマンド構文 ​

レガシーコマンド ​

トラブルシューティング ​

「Change not found」 ​

「No artifacts ready」 ​

「Schema not found」 ​

コマンドが認識されない ​

成果物が正しく生成されない ​

次のステップ ​

コマンド

クイックリファレンス

デフォルトのクイックパス（`core` プロファイル）

拡張ワークフローコマンド（カスタムワークフロー選択）

コマンドリファレンス

`/opsx:propose`

`/opsx:explore`

`/opsx:new`

`/opsx:continue`

`/opsx:ff`

`/opsx:apply`

`/opsx:update`

`/opsx:verify`

`/opsx:sync`

`/opsx:archive`

`/opsx:bulk-archive`

`/opsx:onboard`

AI ツール別のコマンド構文

レガシーコマンド

トラブルシューティング

「Change not found」

「No artifacts ready」

「Schema not found」

コマンドが認識されない

成果物が正しく生成されない

次のステップ