| name | backend-spec-updater |
| description | docs/spec/ 配下の既存仕様書を新しい決定事項や変更に合わせて更新する。差分をわかりやすく提示し、整合性を保ちながら最小限の変更で書き換える。「spec 更新して」「仕様書を最新化して」などで起動。 |
Spec Updater
既存の仕様書を安全に更新する。全面書き換えではなく 最小差分 を志向する。
いつ使うか
- 既存機能に決定事項が追加・変更された
- 機能拡張や廃止で既存 spec との整合性が崩れた
- レビュー指摘で仕様書の文言を直したい
実行手順
1. 対象 spec の特定
- ユーザーが指定したファイルがあればそれを使う
- 指定なしの場合、
docs/spec/ を Glob でリストし、機能名から推定
- 候補が複数ある場合はユーザーに確認
2. 変更理由のヒアリング
以下のどれに該当するかを確認:
- A. 決定事項の追記: 既存セクションに項目追加
- B. 仕様変更: 既存の記述を差し替え
- C. 廃止: セクション削除（削除履歴を残すか確認）
- D. リファクタ: 構成変更、誤字修正、表現改善
3. 影響範囲の調査
Spec 内の他セクションや、他の spec から参照されている箇所を確認:
Grep で同ファイル内の関連語句を検索docs/spec/ 全体から当該 spec への参照を検索- ルール ID（R-01 など）が参照されている場合、ID を維持する
4. 差分プレビュー
書き換え前に、変更プランをユーザーに提示:
変更理由: <A/B/C/D と説明>
変更するセクション:
- 3.2 <ユースケース名>: ルール R-05 の挙動を変更
- 4. ビジネスルール: R-05 の本文差し替え
- 6. エラー・境界条件: <条件> の行を追加
影響ありそうな他 spec:
- docs/spec/<other>.md から R-05 への参照あり（要確認）
この内容で更新しますか？
5. 書き換え実行
Edit ツールで最小差分の置換を行う。全文 Write は避ける（レビュー困難、意図せぬ変更混入の原因）。
- ルール ID は可能な限り維持。廃止時は
~~R-05~~ (廃止: YYYY-MM-DD) のように打ち消しで残す選択肢も提示
- セクション番号がずれる場合は、参照している他箇所も同時更新
6. 変更履歴
プロジェクトに仕様書の更新履歴を残す慣習がある場合（ファイル末尾の「変更履歴」セクション等）、それに従う。ない場合はユーザーに作成を提案。
やらないこと
- 無関係なセクションの書き換え（「ついでに整えた」は禁物）
- 推測による補完（不明点はユーザーに聞く、または「未決定」と明記）
- 実装詳細の混入（
backend-spec-creator の原則参照）
関連
