backend-spec-updater

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 の原則参照）

関連

• backend-spec-creator — 新規仕様の作成
• backend-work-planner — 更新後の仕様を元に実装計画を立てる