openspec-continue-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 のような書き込みコマンドを実行すると、副作用としてディレクトリが作成されます。このコマンドはゼロ以外の終了コードを返しますが、それはエラーではなく、確認結果を示しています。再試行したり回避策を講じたりせず、JSON を確認してください。

1 つだけ例外があります。status のエラーメッセージが Declared in または Invalid store declaration in で始まり、このプロジェクトの openspec/config.yaml（または config.yml）を指している場合、プロジェクトは宣言したストアを通じて OpenSpec を使用していますが、このマシンでは解決できません（ストアが登録されていないか、store: 行の形式が誤っています）。未初期化と見なして以下の分岐に進んではいけません。書き込みを行う前に停止し、そのエラーの message と fix をユーザーに提示してください。

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

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

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

入力： 変更名は任意で指定できます。省略された場合は、会話の文脈から推測できるか確認してください。曖昧な場合や判断できない場合は、利用可能な変更を必ずユーザーに尋ねてください。

手順

1. 変更を選択する

   名前が指定されている場合は、それを使用します。指定されていない場合は、次のようにします。

   • ユーザーが変更について言及していれば、会話の文脈から推測する
   • アクティブな変更が 1 つだけなら、自動選択する
   • 判断できない場合は、openspec list --json を実行して、最終更新日時の新しい順に並んだ変更を取得し、ユーザーに選択してもらう

   選択を尋ねる際は、最終更新日時が新しい変更を上位 3～4 件、選択肢として提示します。以下を表示してください。

   • 変更名
   • ステータス（例：「0/5 タスク」「完了」「タスクなし」）
   • 最終更新日時（lastModified フィールドの値を使用）

   ユーザーが続けようとしている変更である可能性が高いため、最終更新日時が最も新しい変更に「（おすすめ）」と付けてください。

   必ず「使用する変更：」と、その変更を切り替える方法（例：/openspec-continue-change <other>）を伝えてください。

2. 現在のステータスを確認する

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

   JSON を解析して現在の状態を把握します。レスポンスには次の情報が含まれます。

   • schemaName：使用中のワークフロースキーマ（例：「spec-driven」）
   • artifacts：ステータス（「done」「skipped」「ready」「blocked」）が記されたアーティファクトの配列
   • isPlanningComplete：すべての計画アーティファクトが完了しているかを示すブール値。古い CLI バージョンでは、同じ値が isComplete として公開されます。
   • planningHome、changeRoot、artifactPaths、actionContext：パスとスコープのコンテキストです。リポジトリ内のパスだと決めつけず、これらを使用してください。

3. ステータスに応じて対応する：

   ---

   何よりも先に、途中まで書かれたアーティファクトを完成させる：

   • 出力が glob パターン（例：specs/**/*.md）であるアーティファクトは、該当するファイルが1つでも存在すれば「done」と判定されます。そのため、ファイルの書き込み中に処理が中断されると、一部のファイルが欠けた状態でも「done」のままになります。
   • このような「done」アーティファクトごとに、まず手順を取得し、必要な完成済みの依存アーティファクトを読んで、想定されるファイルを特定します。次に、それらのファイルと artifactPaths.<id>.existingOutputPaths を照合します。spec-driven の specs では、提案を読み、そこに記載された各 capability に対して specs/<capability-path>/spec.md が1つずつあることを確認します。比較する前に、想定される各パスを changeRoot を基準に解決してください。また、シンボリックリンクを解決した後も、各パスが changeRoot の内側にあることを、その親ディレクトリとファイルがすでに存在する場合はファイル自体の両方について確認してください。
   • この確認に失敗した想定パスには、決して書き込まないでください。処理を停止してユーザーに伝えます。不足しているファイルがある場合は、確認済みのパスに不足分だけを書き込みます。instruction フィールドでスキルまたはコマンドに作成を委任している場合は、確認済みのパスに各ファイルを書き込める場合に限り、それを実行してください。そうでなければ、処理を停止してユーザーに伝えます。その後、処理を終了します。これが今回の実行で行う唯一のアーティファクト操作となります。ファイルが意図的に省略されたのか判断できない場合は、ユーザーに確認してください。

   ---

   すべての計画アーティファクトが完了している場合（isPlanningComplete: true、または旧形式の isComplete: true）：

   • ユーザーを祝福します。
   • 使用したスキーマを含む最終ステータスを表示します。
   • 次のように提案します。「計画が完了しました。この変更を実装できます。実装と追跡対象の作業が完了したら、アーカイブしてください。」
   • 処理を終了します。

   ---

   作成可能な成果物がある場合（ステータスに status: "ready" の成果物が表示されている場合）：

   • ステータス出力から、status: "ready" の最初の成果物を選びます
   • その指示を取得します：

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

   • JSON を解析します。主なフィールドは次のとおりです：
     • context：プロジェクトの背景情報（あなたへの制約です。出力には含めないでください）
     • rules：成果物固有のルール（あなたへの制約です。出力には含めないでください）
     • template：出力ファイルで使用する構成
     • instruction：スキーマ固有のガイダンス
     • resolvedOutputPath：成果物を書き込む解決済みのパスまたはパターン
     • dependencies：コンテキストとして読み込む完了済みの成果物（skipped: true の項目にはファイルがないため、探さないでください）
     • skipped／warning：変更で skip_specs が宣言され、この成果物を作成してはならない場合に表示されます。別の成果物を選んでください
   • 成果物ファイルを作成します：
     • 完了済みの依存ファイルがあれば、コンテキストとして読み込みます。会話ですでに確認していても、必ずディスクから再度読み込んでください（ユーザーが編集している可能性があります）
     • 作成を始める前に出力パスを決めます。指示に記載された resolvedOutputPath が glob パターンの場合、スキーマの指示と変更のコンテキストに従って changeRoot 内の具体的なパスを選び、シンボリックリンク解決後も親ディレクトリと、すでに存在する場合はファイル自体が changeRoot の内側にあることを確認してください。そうでない場合は、作業を中止してユーザーに伝えてください。それ以外の場合、出力パスは resolvedOutputPath です
     • instruction フィールドで特定のスキルやコマンドを使った作成が指示されている場合、その出力パスに書き込めるときに限り実行します。書き込めない場合は、作業を中止してユーザーに伝えてください
     • それ以外の場合は、自分で作成します：
       • template を構成として使用し、各セクションを埋めます
       • context と rules を制約として適用しますが、ファイルには含めないでください
       • その出力パスにファイルを書き込みます
     • いずれの場合も、指定した出力パスに成果物ファイルが存在することを確認します
   • 作成したものと、新たに着手可能になったものを示します
   • 成果物を1つ作成したら、そこで終了します

   ---

   作成可能な成果物がない場合（すべてブロックされている場合）：

   • この状況は、有効なスキーマであれば発生しないはずです
   • ステータスを表示し、問題の確認を提案します

4. 成果物を作成した後、進捗を表示します

   openspec status --change "<name>"
   

出力

実行するたびに、次の内容を表示します：

• 作成した成果物
• 使用中のスキーマワークフロー
• 現在の進捗（完了数 N/M）
• 新たに着手可能になった成果物
• 次のプロンプト：「続けますか？続けるよう依頼するか、次に何をすればよいか教えてください。」

成果物作成のガイドライン

成果物の種類と目的はスキーマによって異なります。各成果物の指示では、instruction フィールドが最優先のガイダンスです。proposal.md や tasks.md など、見慣れた名前の成果物でも、カスタムスキーマによって同じファイル名に異なる内容や手順が定義されている場合があるため、指示に従ってください。

instruction フィールドで特定のスキルやコマンドを使った作成が指示されている場合は、成果物を直接書くのではなく、それを実行してください。ただし、出力パスを決定して確認した後であり、そのパスに書き込める場合に限ります。

ガードレール

• 1回の実行につき、成果物は1つだけ作成します
• 新しい成果物を作成する前に、依存する成果物を必ず読み込みます。会話の記憶ではなく、ディスクから再度読み込んでください（前回の確認後にファイルが変更されている可能性があります）
• 成果物を飛ばしたり、順序を入れ替えて作成したりしないでください
• コンテキストが不明確な場合は、作成前にユーザーに確認してください
• 進捗を完了として扱う前に、書き込み後の成果物ファイルの存在を確認してください
• スキーマで定義された成果物の順序を使用し、特定の成果物名を前提にしないでください
• 重要：context と rules はあなたへの制約であり、ファイルに記載する内容ではありません
  • <context>、<rules>、<project_context> ブロックを成果物にコピーしないでください
  • これらは作成内容を導くためのものであり、出力に含めてはいけません