OpenSpec (OPSX) スキル

OpenSpec artifact-driven workflow システム (OPSX) をガイドまたは推論するためにこのスキルを使用します。artifact グラフ、schema/template の解決、変更ライフサイクル、および実験的なコマンド/スキルが含まれます。

クイックナビゲーション

• Artifact グラフのコア概念: references/artifact-core.md
• OPSX ワークフロー動作と使用方法: references/opsx-workflow.md
• セットアップ + プロファイル (init, update, config profile): references/setup-profiles.md
• Schema カスタマイズ ワークフローとギャップ: references/schema-customization.md
• エンドツーエンド schema ワークフローギャップと提案ソリューション: references/schema-workflow-gaps.md
• 実験的リリース計画とロールアウト チェックリスト: references/experimental-release-plan.md

リリース ハイライト (1.2.0 → 1.3.0)

• ツール統合の拡充: Junie、Lingma、ForgeCode、IBM Bob のサポートが追加されました。
• より安全なセットアップ: シェル補完のインストールはオプトインになり、Copilot の自動検出は .github/ ディレクトリだけでは発動しなくなりました。
• アダプター修正: Pi コマンド生成が修正され、OpenCode は標準的な .opencode/commands/ パスを使用するようになりました。
• より安全なステータス確認: openspec status はプロジェクトにまだ変更がない場合、きれいに終了します。

OPSX コマンド

コマンド	目的
/opsx:explore	アイデアを検討し、問題を調査 (構造なし)
/opsx:new	新しい変更を開始
/opsx:continue	依存関係に基づいて次の artifact を作成
/opsx:ff	高速フォワード — すべての計画 artifact を一度に作成
/opsx:apply	タスクを実装し、必要に応じて artifact を更新
/opsx:verify	実装が仕様と一致することを検証
/opsx:sync	デルタ spec をメイン spec に同期
/opsx:archive	完了した単一の変更をアーカイブ
/opsx:bulk-archive	完了した複数の変更を一度にアーカイブ

レガシー (OPSX 以外) コマンド: /openspec:proposal はすべての計画 artifact を一度に作成します。OPSX を推奨しますが、小規模またはシンプルな変更、または古いセットアップの場合に便利です。

Schema 管理

openspec schemas                    # 利用可能な schema を一覧表示
openspec schema which --all         # 解決ソースを表示
openspec schema init my-workflow    # 新しい schema を対話的に作成
openspec schema fork spec-driven my-workflow  # 既存 schema をフォーク
openspec schema validate my-workflow  # schema 構造を検証

プロジェクト設定

プロジェクト単位の設定のために openspec/config.yaml を作成:

schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  Testing: Vitest, Playwright

rules:
  proposal:
    - Include rollback plan
  specs:
    - Use Given/When/Then format

Schema の優先順位: CLI フラグ → 変更メタデータ → プロジェクト設定 → デフォルト (spec-driven)

コア概念

• Artifact グラフ、ワークフロー エンジンではない: 依存関係はアクションを有効にします。線形フェーズを強制しません。
• ファイルシステム アズ データベース: 完了は保存された状態ではなく、ファイルの存在から導出されます。
• 決定的 CLI: コマンドには明示的な変更コンテキストが必要です (エージェントが推論し、CLI は厳密なままです)。
• XDG schema 解決: ユーザー上書きは組み込み schema より優先されます。
• Template は schema スコープ: Template は schema の隣に配置され、厳密な 2 レベルのフォールバックで解決されます。

判定ルール

• インテントが同じで、スコープまたはアプローチを洗練させる場合は update を推奨します。
• インテントまたはスコープが根本的に変わる場合、または元の変更を独立して完了できる場合は 新規変更 を推奨します。
• artifact が変更された理由の明確な履歴を常に保持します (proposal/specs/design/tasks)。

レシピ

1) 次に作成する準備ができているものを表示

1. アクティブな変更 id を決定します。
2. 変更を明示的に設定した状態で、ステータスと準備完了 artifact をクエリします。
3. 準備完了 artifact とその依存関係を提示します。

期待される動作: 必要なステップではなく、準備完了 artifact を表示します。

2) 特定の artifact の指示を生成

1. XDG フォールバックで schema と template を解決します。
2. コンテキストを構築: 変更メタデータ、依存関係ステータス、ターゲット パス。
3. プレーン Markdown で富化された指示を返します。

3) 新しい変更を開始

1. 変更名を検証 (kebab-case)。
2. 変更ディレクトリと README を作成します。
3. 初期ステータスと最初の準備完了 artifact を表示します。

4) Schema カスタマイズ ガイダンス

1. XDG 上書きパスを説明します。
2. 組み込み schema + template のコピーについて説明します。
3. 検証ステップまたは推奨される CLI コマンド (リストと解決) を提供します。

5) 変更のための schema バインディングを説明

1. 利用可能な場合は変更メタデータを優先します。
2. 設定されている場合はプロジェクト デフォルト schema にフォールバックします。
3. それ以外の場合は spec-driven にデフォルト設定します。

禁止事項

• システムを線形ワークフロー エンジンとして扱わないでください。
• 明示的な選択なしに、変更がアクティブであると仮定しないでください。
• レポートなしに schema または template 間で黙々とフォールバックしないでください。
• 長いベンダー ドキュメントを逐語的にコピーしないでください。要約し、実行可能なガイダンスを提供します。

出力期待値

• artifact の準備完了と依存関係の説明を明確にします。
• 例で明示的な変更識別子を使用します。
• 簡潔で実行可能なステップを提供し、それが情報提供性か必須かを示します。

リンク

• Documentation
• Releases
• GitHub
• npm