変更の編集と反復

change 内の成果物はすべて、いつでも編集できる Markdown ファイルです。 固定された「計画フェーズ」も、承認ゲートも、特別な編集モードもありません。実装開始後に提案を変更したくなったら、proposal.md を開いて編集してください。実装中に設計の誤りに気付いたら、design.md を直して作業を続けます。それが答えのすべてであり、意図された設計です。

「ちょっと待って、戻って変更できるの？」と思ったときのためのページです。もちろんできます。よくあるケースごとに方法を説明します。

あらゆるものを編集する2つの方法

いつでも次の2つの方法を使えます。

1. ファイルを直接編集する。 成果物は openspec/changes/<name>/ 内の通常の Markdown ファイルです。エディターで proposal.md、design.md、tasks.md、または specs/ 内の差分仕様を開いて編集してください。それ以外に必要なことはありません。

2. AI に修正を依頼する。 チャットで「キャッシュ案を外してレート制限の節を追加するよう提案を更新して」や「ポーリングではなくキューを使う設計にして」と伝えるだけです。AI は change の他の内容を文脈として参照し、成果物を編集します。

状況に合う方法を使ってください。表現を少し直すならファイルを編集し、方針を大きく考え直すなら、全体の文脈を踏まえて AI に修正してもらいます。

「開始後に提案（または仕様）を更新するには？」

そのまま更新してください。同じ change を洗練させるだけです。

拡張コマンドを使っている場合は、成果物を編集してから /opsx:continue を実行し、新しい状態から再開するか、更新した計画に沿って実装を続けるため /opsx:apply を実行します。既定の core コマンドを使っている場合は、成果物を編集して /opsx:apply を実行してください。現在のファイルを読み込むため、更新後の内容に沿って実装されます。

成果物は署名済みの契約ではなく、常に更新される計画だと考えてください。AI は常に現在の内容に基づいて作業するので、成果物を編集すれば作業の方向を調整できます。

あなた: この change の進め方を変えたいです。

あなた: [design.md を編集するか、AI に伝えます:]
     同期呼び出しではなくバックグラウンドジョブを使うよう design.md を更新してください。

AI:  design.md を更新しました。タスクリストはそのまま使えます。実装を続けますか？

You: /opsx:apply

よくある質問への答えは、専用の「提案を更新」コマンドは必要ない、ということです。ファイルが真実の情報源なので、手動でも AI 経由でも、ファイルを編集すること自体が更新になります。

「実装後にレビューへ戻るには？」

「戻る」必要はありません。レビューから離れていないからです。ワークフローは柔軟で、レビュー、編集、実装は一度入ると抜けられないような直列のフェーズではありません。

具体的には、/opsx:apply で作業を進めた後でも、次のことができます。

• 計画を再確認するには、成果物を開いて読むか、ターミナルで openspec show <change> を実行してまとめて表示します。
• 変更点が見つかったら、成果物を編集する（または AI に依頼する）だけで、そのまま続けられます。
• コードが計画どおりか体系的に確認するには、拡張コマンドの /opsx:verify を実行します。作業を妨げることなく、完全性、正確性、一貫性を報告します。ワークフロー: Verifyを参照してください。

いつでも、実装後であってもレビューできるので、「戻る」対象となるレビュー専用フェーズはありません。

「手動でコードを編集しました。OpenSpec と整合させるには？」

これはよくあることで、問題ありません。エディターでコードを変更したため、コードと成果物の内容が一致しなくなったとします。正しい側に合わせて、両者を同期してください。

• コードは正しく、仕様が古くなっている。 実際に実装した動作を記述するよう、差分仕様（必要ならタスクも）を更新してください。アーカイブすると仕様が真実の情報源にマージされるため、アーカイブ前に仕様を実態と一致させます。
• 仕様は正しく、コードがずれている。 コードが仕様と一致するまで実装や修正を続けます。

食い違いをすばやく見つけるには /opsx:verify を使います。成果物とコードを読み、どこが異なるかを示します。その結果を整合のためのタスクリストとして扱い、両者が一致したらアーカイブしてください。

原則として、アーカイブ時に仕様が公式な記録になります。したがってアーカイブ前に、コードの動作を正しく表す仕様にしてください。手動編集は歓迎ですが、気付かないうちに仕様とずれたままにしないでください。

納得できない提案を洗練する

生成された提案が期待と違う場合は、次の3つの方法があります。

• 同じ change 内で反復する。 「範囲が広すぎるので、管理者向け機能を外して」といった問題点を AI に伝えて修正してもらいます。最も手軽で、たいていはこれで十分です。
• 先に explore してから提案し直す。 アイデア自体が曖昧なら、/opsx:explore に戻って考えを整理し、より明確な提案につなげます。まず Exploreを参照してください。
• 新しく始める。 目的が根本的に変わった場合、古い change を修正するより新しい change を作る方が明快です。

最後の方法を選ぶかどうかは、次の判断ガイドを参考にしてください。

更新するか、新しい change を始めるか

要点は、同じ作業を洗練するなら更新し、目的が根本的に変わったり範囲が別の作業にまで広がったりしたら新しく始めることです。

• 目的は同じで、方法を改善する場合は更新します。
• 範囲を縮小する（今は MVP をリリースし、残りは後で対応する）場合は、更新してからアーカイブし、第2段階用に新しい change を作成します。
• 問題自体が変わった（「ダークモードの追加」が「完全なテーマシステムの構築」に変わった）場合は、新しく作成します。

詳しいフローチャートと例はワークフロー: 更新するか新しく始めるかに、さらに詳しい説明はOPSX: 更新するか新しく始めるかにあります。

タスクについて

tasks.md は固定された計画ではなく、常に更新されるチェックリストです。実装中に気付いたタスクを追加したり、不要と分かった項目を削除したり、順序を変えたりできます。AI は /opsx:apply 中に完了した項目へチェックを付け、後で再開した場合は最初の未完了タスクから続けます。作業途中でリストを編集することも想定されています。

次に読むページ

• ワークフロー — パターンと、更新するか新しく始めるかの判断ガイド
• 変更のレビュー — 実装前に計画を2分で確認する方法
• まず Explore — アイデアを考え直すときに立ち返る場所
• コマンド — /opsx:continue、/opsx:apply、/opsx:verify の詳細
• 概念: 成果物 — 各成果物の役割