openspec-new-change

実験的なアーティファクト駆動型アプローチを使って、新しい変更を開始します。

ストアの選択： ユーザーがストア（ストアとは、このマシンに登録されている独立した OpenSpec リポジトリです）を指定した場合、または作業対象がストア内にある場合は、openspec store list --json を実行して登録済みのストア ID を確認し、仕様と変更を読み書きするコマンド（new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）に --store <id> を渡してください。選択したら、ワークフローの残りの間は --store <id> を常に指定してください。以下にある、ストアを指定していないコマンドの例は、すべて省略形です。実行する前にフラグを追加してください。たとえば、以下に示すストアを指定していない形式ではなく、openspec status --change "<name>" --json --store "<id>" を実行します。それ以外のコマンドでは、このフラグは使いません。コマンドが出力するヒントには、すでにフラグが含まれています。後続のコマンドでもフラグを付けたままにしてください。ストアを指定しない場合、コマンドは最も近いローカルの openspec/ ルートに対して動作します。

プロジェクトの確認： これらの手順では、すでに OpenSpec を使用しているプロジェクトを想定しています。最初に何かを書き込む手順（new change、archive、sync specs、またはアーティファクトファイルの作成）を実行する前に、プロジェクトにルートがあることを確認してください。openspec list --json を実行し（ストアが選択されている場合は、そのストアがルートとなるため --store <id> を付けます）、root を読み取ります。ルートオブジェクトがあれば、プロジェクトのセットアップは完了しています。"root": null は、セットアップされていないことを意味します。ここに openspec/ ディレクトリはなく、openspec new change などの書き込み操作を行うと、副作用として作成されます。このコマンドはゼロ以外の終了コードも返しますが、これはエラーや CLI の不具合ではなく、答えを示しています。再試行したり回避策を試したりせず、JSON を読み取ってください。

ただし、status のエラーメッセージが Declared in または Invalid store declaration in で始まり、このプロジェクトの openspec/config.yaml（または config.yml）を示している場合、"root": null はセットアップの問題ではありません。このプロジェクトは、自身が宣言しているものの、このマシンでは解決できないストア（登録されていないストア、または不正な store: 行）を介して OpenSpec を使用しています。初期化されていないと判断して以下の分岐を進めてはいけません。書き込みの前に停止し、そのエラーの message と fix をユーザーに示してください。

それ以外の場合、ルートがないときの次の対応は、このワークフローに至った経緯によって異なります。

• 自動選択： ユーザーが OpenSpec に言及したり、このスキルを指定したり、スラッシュコマンドを実行したりせず、自分でこのワークフローを選んだ場合です。OpenSpec の使用をやめ、OpenSpec がインストールされていない場合と同様に、通常どおりリクエストに回答してください。セットアップを促したり、OpenSpec のセットアップについて触れたりしないでください。
• 明示的な OpenSpec リクエスト： ユーザーが OpenSpec に言及した、このスキルを指定した、またはそのスラッシュコマンドを実行した場合です。書き込みの前に停止し、どのように進めるかを尋ねてください。このプロジェクトをセットアップする（openspec init）、すでにあるストアを対象にする（--store <id>）、または今回のリクエストでは OpenSpec を使わずに進める、のいずれかです。回答を待ってください。

どちらの分岐でも、副作用としてルートを作成してはいけません。ユーザーから依頼されるまで openspec init を実行せず、openspec/ ファイルを手動で作成せず、コマンドによってルートが作成されることも避けてください。

入力： ユーザーのリクエストには、変更名（kebab-case）または作成したいものの説明を含めてください。

手順

1. 明確な入力がない場合は、何を作りたいか尋ねる

   ユーザーに自由回答形式で尋ね、選択肢は提示しないでください。

   「どのような変更に取り組みたいですか？作成または修正したいものを説明してください。」

   説明から kebab-case の名前を導き出します（例：「ユーザー認証を追加する」→ add-user-auth）。

   重要： ユーザーが何を作りたいのかを把握するまで、先に進んではいけません。

2. ワークフローのスキーマを決定する

   ユーザーが別のワークフローを明示的にリクエストしない限り、デフォルトのスキーマを使用します（--schema は省略します）。

   ユーザーが次のように述べた場合に限り、別のスキーマを使用します。

   • 特定のスキーマ名を指定した場合 → --schema <name> を使用します
   • 「ワークフローを表示して」または「どんなワークフローがあるの？」と尋ねた場合 → openspec schemas --json を実行し、ユーザーに選んでもらいます

   それ以外の場合： デフォルトを使用するため、--schema は省略します。

3. 変更ディレクトリを作成する

   openspec new change "<name>"
   

   ユーザーが特定のワークフローを指定した場合に限り、--schema <name> を追加します。 これにより、CLI が解決したプランニングホームに、ひな形となる変更が作成されます。

4. 成果物のステータスを表示する

   openspec status --change "<name>" --json
   

   リポジトリ内のパスを推測するのではなく、返された planningHome、changeRoot、artifactPaths、nextSteps を使用します。

5. 最初の成果物の手順を取得する 最初の成果物はスキーマによって異なります（たとえば、仕様駆動型の場合は proposal）。 ステータス出力を確認し、ステータスが「ready」の最初の成果物を見つけます。

   openspec instructions <first-artifact-id> --change "<name>"
   

   これにより、最初の成果物を作成するためのテンプレートとコンテキストが出力されます。

6. 停止して、ユーザーの指示を待つ

出力

手順の完了後、次の内容を要約します。

• 変更名と場所
• 使用するスキーマ／ワークフローと、その成果物の順序
• 現在のステータス（N 件中 0 件の成果物が完了）
• 最初の成果物のテンプレート
• プロンプト：「最初の成果物を作成しますか？この変更の概要を説明していただければ下書きを作成します。または、続行するよう指示してください。」

ガードレール

• まだ成果物を作成しないでください。手順を表示するだけにします
• 最初の成果物のテンプレートを表示した先へ進まないでください
• 名前が無効（ケバブケースではない）な場合は、有効な名前を尋ねてください
• 同じ名前の変更がすでに存在する場合は、その変更を続けるよう提案してください
• デフォルト以外のワークフローを使用する場合は、--schema を渡してください