Architecture Change Communication

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 設計変更の影響範囲・通知計画・非推奨措置をチェックリスト型で評価し、コミュニケーション漏れを防ぐ

Goal / 目的

• 設計変更の差分から、影響範囲・通知経路・非推奨措置を共有するコミュニケーション計画が抜け落ちていないかをチェックする。

Non-goals / 扱わないこと

• 内部通知ツール（Slack/Teams）のテンプレ作成や運用作業そのもの。
• 個別チームの予定調整（ただし通知対象に入るべきステークホルダーは指摘する）。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• 差分に設計ドキュメント（アーキテクチャ/ADR/設計書）の変更がある
• 差分にアーキテクチャ変更・API変更・非推奨化など影響範囲を伴う記述の追加または変更がある
• inputContextにdiffが含まれている

ゲート不成立時の出力: NO_REVIEW: change-communication — コミュニケーション計画が必要な設計変更が検出されない

False-positive guards / 抑制条件

• すでに別 ADR/通知チャネルで整備されており、差分がその参照のみであれば重複指摘を避ける。

Rule / ルール

• 先頭に要約を 1 行出す（影響範囲・通知・非推奨/移行の要点）。
• 指摘は最大 8 件。ステークホルダー漏れ、通知対象不明、移行/非推奨の曖昧さを優先。
• 可能なら「通知文/説明テンプレ」を添える（貼れる短文）。

Checklist / 観点チェックリスト

• 影響範囲
  • 変更が影響するサービス/チーム/ドメインを列挙しているか。
  • オーナー/責任者（Team/Role）が明記されているか。
• 通知計画
  • 変更を知らせるチャネル（release notes, mailing list, status page 等）が決まっているか。
  • スケジュール（いつ通知し、いつ施行するか）があるか。
  • 非推奨・移行
  • 旧バージョン/機能の非推奨状況と移行締切があるか。
  • 互換性の切り分け（どのクライアント/サービスが動かなくなるか）が説明されているか。
• 継続的整合
  • ドキュメント/ADR/図の更新が必要な箇所が TODO/追跡対象としてリストされているか。
  • コミュニケーションの経路（誰が更新するか）を明示しているか。

Output / 出力フォーマット

すべて日本語。<file>:<line>: <message> 形式で出力。

• 先頭に要約行: (summary):1: <影響範囲/通知/非推奨の要点>
• 指摘（最大8件）:
  • [severity=critical|major|minor|info] を含める。
  • 可能なら「通知テンプレ」等を追加。

例:

• docs/architecture/change.md:42: [severity=major] 公開API影響が未通知。Fix: 12月14日 15:00に release-notes へ通知予定と明記。

評価指標（Evaluation）

• 合格: 影響範囲・通知計画・移行方針に抜けがないかを差分に紐づく形で指摘し、アクションに結びつく遷移案がある。
• 不合格: 一般論やオペレーションの詳細、差分と無関係なステークホルダー批判。

人間に返す条件（Human Handoff）

• 組織的なポリシー変更や交渉が必要な場合は人間レビューへ。