improve-architecture

アーキテクチャを改善する

具体的なアーキテクチャ上の摩擦を見つけ、まだ必要な判断だけを明確にします。

architecture-language.md、engineering-discipline.md、およびリポジトリにある場合は Glossary／ADR を使用します。

境界

• このスキルは、改善の機会を見つける場合や、未解決のモジュール／インターフェース／境界の選択を明確にする場合に使用します。
• 具体的な変更、PR、またはフェーズにおけるアーキテクチャの評価には review-work を使用します。
• 動作を維持したまま簡素化することがすでに決まっている場合は simplify-work に、その他の実装が決まっている場合は implement-work に引き継ぎます。候補の選定、ヒアリング、Plan、または引き継ぎを無理に行う必要はありません。
• レビューでこのスキルを推奨することはできますが、自動的に開始してはいけません。

調査

1. 呼び出し元から見える利用方法を起点にします。モジュール、所有権、インターフェース、境界を明確にするために必要な、最小限で有用な呼び出し、コンポーネント、データ、または制御フローの図を作成します。
2. 根拠のある摩擦を特定します。たとえば、知識の分散、単純な受け渡しにとどまるレイヤー、詳細の漏出、回避可能な分岐や可変状態、テストしにくい動作、変更の波及、所有権の不明確さ、無効な状態を許すデータモデルなどです。
3. ユーザーが対象領域をまだ選んでいない場合に限り、候補を少数に絞り、優先順位を付けて提示します。
4. 選ばれた候補について、重要な制約、移行、検証、呼び出し元への影響だけを明確にします。
5. 次に役立つ最小限の成果物を提示します。推奨案、インターフェースの選択、範囲を限定した simplify-work または implement-work の作業範囲、Plan の依頼、または引き継ぎが該当します。デフォルトで Plan を作成したり、引き継いだりしてはいけません。

候補の概要には、対象領域、確認された摩擦、改善の機会、メリット、リスク、根拠を記載します。

インターフェースまたは境界の選択

配置が本当に未解決の場合は、呼び出し元への影響、隠れた複雑さ、移行コスト、テスト容易性、変更の起こりやすさ、所有権の観点から、実質的に異なる選択肢を2つまたは3つ比較し、1つを推奨します。配置が明らか、または変更されない場合は、この手順を省略します。

アーキテクチャ用語は経験則として扱います。1つのアダプターでも、変更の起こりやすさ、所有権、またはテストを切り分けるなら境界を設ける根拠になります。その境界が何を保護するのかを確認します。テストだけのために内部を公開するのではなく、動作を検証するテスト対象には、公開インターフェースまたは意図的に安定させたインターフェースを優先します。

大規模な書き直しを提案したり、新たな摩擦がないのに ADR を蒸し返したり、通常の機能開発で不必要にアーキテクチャ用語を使ったりしてはいけません。