openspec-update-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-continue-change は省略可能なワークフローであり、インストールされていない場合があります。以下で提案する前に、利用可能か確認してください。利用できない場合は、openspec status --change "<name>" --json で次のアーティファクトを確認でき、openspec instructions "<artifact-id>" --change "<name>" --json でその作成方法を確認できます。

手順

1. 変更を選択する

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

   • ユーザーが会話の文脈で変更に言及していれば、そこから推測します
   • アクティブな変更が 1 つだけの場合は、自動選択します
   • 曖昧な場合は、openspec list --json を実行し、最終更新日時の新しい順に並べられた変更を取得して、ユーザーに選択を求めます

   ユーザーに尋ねるときは、最終更新日時の新しい変更を上位 3～4 件提示し、以下を表示します：

   • 変更名
   • スキーマ（schema フィールドがあればその値、なければ「spec-driven」）
   • ステータス（例：「タスク 0/5 件」「完了」「タスクなし」）
   • 最終更新日時（lastModified フィールドの値）

   最も最近更新された変更には、ユーザーが更新したい変更である可能性が高いため、「（おすすめ）」と付けます。

   必ず「変更を使用しています：」と、変更方法（例：/openspec-update-change <other>）を伝えます。

2. 変更のアーティファクトを取得する

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

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

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

   アーティファクト ID とパスはアクティブなスキーマに基づきます。これらを決めつけたり、ハードコードしたアーティファクト名で分岐したりしないでください。カスタムスキーマも変更なしで動作する必要があります。

   編集するファイルは artifactPaths.<id>.existingOutputPaths です。これはディスク上に存在する具体的なファイルで、glob アーティファクトの場合はすでに glob が展開されています（例：specs/**/*.md）。resolvedOutputPath には書き込まないでください。glob アーティファクトの場合、これは実ファイルではなく glob パターンのままです。

3. リクエストを理解する

   • ユーザーが具体的な改訂内容（「設計では現在 X を使用する」など）を求めた場合、それを編集の出発点とします。
   • 「更新して」「一貫性を持たせて」とだけ依頼された場合は、一貫性のレビューとして扱います。既存のアーティファクトを読み、相互に照らし合わせて矛盾、抜け、重複を確認します。

4. 読み取りと整合性の確認

   • 依頼の対象となる成果物と、この変更に関連する既存の他の成果物を読みます。
   • 依頼された編集を行います。その後、ほかの既存の成果物すべてと照合します。方向は問いません。後の成果物の編集によって、前の成果物の修正が必要になる場合もあります。ビルド順は読み進める際の参考であり、修正できる成果物を制限するものではありません。
   • 不整合、欠落、矛盾が新たに生じた箇所をすべて記録します。
   • すでに存在するファイル（existingOutputPaths）のみを修正します。まだ存在しない成果物は作成しないでください。また、glob 成果物の下に新しいファイルを作成しないでください。その旨を記録し、作成のため /openspec-continue-change を案内します。
   • 変更にすでに整合性がある場合は、その旨を伝え、編集は行いません。

5. 一つずつ確認し、適用する

   • 提案する修正とその理由を一つずつ提示します。ユーザーの確認後にのみ書き込みます。
   • ユーザーが修正を却下した場合は書き込まず、その成果物は変更しません。
   • 大幅な書き換えが必要な場合は、まずその成果物のルールとテンプレートを取得します。

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

6. 次のステップを案内する（案内のみ。決して実行しないでください）

   • まだ存在しない成果物がある場合は、作成のため /openspec-continue-change を提案します。
   • 変更がすでに実装済み（タスクが完了済み、またはすでに適用済み）の場合は、コードが修正後の計画と一致しなくなっている可能性があります。コードに差分を反映するため /openspec-apply-change を提案します。
   • すべて完了し、実装も済んでいる場合は、/openspec-archive-change を提案します。

出力

呼び出しのたびに、次の内容を示します。

• 修正した成果物（および却下された修正案）
• /openspec-continue-change に委ねる事項（まだ作成されていない成果物やファイル）
• 変更の現在の状況と、次に推奨するコマンド

ガードレール

• 計画用成果物のみを扱います。実装コードは決して編集しないでください。修正後の計画にコード変更が必要な場合は、そこで停止し、/openspec-apply-change を案内します。
• openspec status が報告した成果物 ID とパスを使用します。ハードコードされた成果物名に基づいて処理を分岐しないでください。
• existingOutputPaths にある具体的なファイルのみを編集します。glob の resolvedOutputPath には書き込まないでください。
• ビルドの進行を先に進めないでください。新たな成果物や、glob 成果物の下の新しいファイルを作成する作業は /openspec-continue-change に委ねます。
• すべての編集について、書き込む前にユーザーの確認を得てください。
• 依頼によって変更の「意図」が変わる場合は、まず任意の /openspec-new-change ワークフローが利用可能か確認します。利用可能であれば、 /openspec-new-change で新規に開始することを推奨します（「更新か新規開始か」の判断基準）。利用できない場合は、未使用の変更名を別途指定するようユーザーに尋ね、代わりに openspec new change "<new-change-name>" を推奨します。