菜单
乱雑なコードベースを、明確なパッケージ/モジュール構造に再設計するための指針。 対象は (1) 乱雑なコードの再整理、(2) 単一巨大モジュールの分割、 (3) パッケージ境界のレビュー、(4) 新規プロジェクトのモジュール階層設計。 トリガー：「パッケージ構造を見直したい」「モジュールの依存関係が複雑」 「ファイル配置を整理したい」「循環依存を解消したい」といった構造改善リクエストで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。GitHub Actions の CI ログ分析、ローカル CI （`./scripts/ci-check.sh`）の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。 ループモード（`/loop 5 /pr-green`）にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。 トリガー：「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。
DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること： - 集約(Aggregate)の新規設計・実装・リファクタリング（どの言語でも） - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定（「AとBは同じ集約にすべきか？」「この集約は大きすぎるか？」） - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断（ドメインイベント、結果整合性、Sagaパターン） - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例：集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。
後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル（deprecation cycle）の 制度化、互換層の局所化（Adapter/Strangler Fig）、契約テスト（CDC）による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存（Java, TypeScript, Go, Python, Rust等すべて）。 トリガー：「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。
getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合（永続化、JSON変換など）に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー：「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。
クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造（ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層）に基づく。特にインフラ層は 横断的関心事（ロギング、設定管理）のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。
| name | package-design |
| description | 乱雑なコードベースを、明確なパッケージ/モジュール構造に再設計するための指針。 対象は (1) 乱雑なコードの再整理、(2) 単一巨大モジュールの分割、 (3) パッケージ境界のレビュー、(4) 新規プロジェクトのモジュール階層設計。 トリガー：「パッケージ構造を見直したい」「モジュールの依存関係が複雑」 「ファイル配置を整理したい」「循環依存を解消したい」といった構造改善リクエストで起動。 |
乱雑なコードを、体系立てた分析で整理されたパッケージへ再構成する。
核心: パッケージ設計は「ソースコードの配置」ではなく「変更の波をどこで止めるか」「依存の向きをどう制御するか」の設計問題である。
分割の出発点は「処理手順」ではなく「変化しそうな設計決定」である。
Parnas の情報隠蔽に基づき、まず以下を問う:
出力: 変更理由と影響範囲の対応表
対象コードから原子的な責務を抽出する:
出力: 10〜50件の原子的な責務一覧
責務を分割する際の軸を選択し、グルーピングする。
| 分割軸 | 凝集の性質 | 適するケース | リスク |
|---|---|---|---|
| 機能（feature/vertical） | 変更が縦に閉じる | チーム独立、マイクロサービス候補 | 共通化地獄 |
| ドメイン（業務概念） | 情報的凝集 | ドメインモデルの一貫性重視 | コンテキスト間翻訳コスト |
| レイヤ（技術層） | 技術責務の分離 | 小規模、導入初期 | 1変更が全層に散る |
| 責務（変更理由） | CCP準拠 | 変更頻度が明確 | 初期分析コスト |
| API境界（公開IF） | 表面積最小化 | ライブラリ設計 | 内部柔軟性とのバランス |
出力: 3〜7個の候補パッケージ（認知負荷の観点から7±2が目安）
MECEは「設計の目的」ではなく「網羅性チェックの補助」として使う。 厳密MECEにこだわりすぎると、横断的関心（ログ、認可、トランザクション等）の扱いで境界が薄くなる危険がある。8〜9割の網羅で十分。
詳細は references/principles.md#mece-分割 を参照。
各グループを一段抽象化して命名する:
良い例: authentication, billing, inventory
避ける例: utils, helpers, common, misc
依存は「より安定・より抽象」な側へ向ける。
循環が見つかった場合:
| 原則 | 確認観点 |
|---|---|
| 高凝集 | パッケージ内の要素が単一目的に収束しているか |
| 低結合 | パッケージ間の依存が最小か |
| ADP | 循環依存がないか |
| SDP | 依存が安定側に向かっているか |
| SAP | 安定なパッケージが十分抽象的か |
| CCP | 同じ変更理由のものが同一パッケージに閉じているか |
詳細は references/principles.md を参照。
各パッケージについて:
pub にすべき要素（外部契約）を特定するpub(crate) か private にするテストを「境界」に対応させる:
| テスト種別 | 対象 | 目的 |
|---|---|---|
| ユニットテスト | パッケージ内部 | 内部の凝集を守る |
| 統合テスト | パッケージ間 | 境界横断の依存が設計どおりか |
| 契約テスト | 公開API境界 | 互換性（結合点）を守る |
提案した構造が以下を満たしているか確認する（Yesが多いほど高凝集・低結合）:
| メトリクス | 対象 | 意味 |
|---|---|---|
| Ca（求心結合） | パッケージ | 外部から依存される数 |
| Ce（遠心結合） | パッケージ | 外部へ依存する数 |
| I = Ce/(Ca+Ce) | パッケージ | 不安定性（0=最安定, 1=最不安定） |
| D（Main Sequenceからの距離） | パッケージ | A + I = 1 からの乖離 |
詳細は references/principles.md#パッケージメトリクス を参照。
以下が観測されたら分割/境界の見直しを検討する:
references/rust-patterns.md を参照:
mod 階層設計※ このプロジェクトでは mod.rs を使わない。2018モジュール方式で package_name.rs と package_name/ 配下のファイルで構成する。
| パターン | 凝集軸 | 利点 | リスク |
|---|---|---|---|
| レイヤード | 技術責務 | 導入容易 | 1変更が全層に散る |
| 機能別（vertical slicing） | ユースケース | 変更が閉じやすい | 共通化地獄 |
| コンポーネント別 | 機能集合 | 境界が明確 | 公開API設計コスト |
| Bounded Context | ドメイン境界 | モデル整合性 | コンテキスト間翻訳コスト |
| Ports & Adapters / Clean | 依存方向 | テスト容易 | 構造の形式主義 |
再構成提案は以下の形式で示す:
## 提案パッケージ構成
package_name.rs (目的: 1文で説明)
package_name/
├── submodule_a.rs
└── submodule_b.rs
### 依存関係
package_a → package_b (reason)
### メトリクス概算
package_a: Ca=3, Ce=1, I=0.25 (安定)
package_b: Ca=1, Ce=2, I=0.67 (不安定)
### 移行手順
1. 新しいモジュール構造を作成する
2. 型や関数を最小変更で移動する
3. import を更新する
4. テストが通ることを確認する
5. 循環依存がないことを静的解析で確認する
このスキルを使用する際は、以下のスキルも併せて参照すること：
ddd-module-pattern: DDD文脈でのドメイン語彙ベースのモジュール設計refactoring-packages: 既存パッケージ構造のリファクタリング実行clean-architecture: パッケージ設計の基盤となる4層アーキテクチャ