メニュー
既存コードベースのパッケージ/モジュール構造を分析し、リファクタリングを実行する。 循環依存の検出・解消、神モジュールの分割、責務分離の実施、移行計画の作成と実行を行う。 トリガー：「この依存関係を整理して」「循環依存を解消して」「このモジュールを分割して」 「リファクタリングして」といった既存コードの構造改善実行リクエストで起動。 設計指針が必要な場合は package-design スキルを参照。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | refactoring-packages |
| description | 既存コードベースのパッケージ/モジュール構造を分析し、リファクタリングを実行する。 循環依存の検出・解消、神モジュールの分割、責務分離の実施、移行計画の作成と実行を行う。 トリガー：「この依存関係を整理して」「循環依存を解消して」「このモジュールを分割して」 「リファクタリングして」といった既存コードの構造改善実行リクエストで起動。 設計指針が必要な場合は package-design スキルを参照。 |
既存コードのパッケージ/モジュール構造を分析し、改善提案と移行計画を作成・実行する。
1. 現状分析 → 2. 問題特定 → 3. 改善提案 → 4. 移行計画
対象ディレクトリの構造を把握する。
使用ツール:
mcp__serena__list_dir: ディレクトリ構造の把握（recursive: true）mcp__serena__get_symbols_overview: ファイル内のシンボル把握mcp__serena__find_referencing_symbols: 依存関係の検出確認ポイント:
references/analysis-patterns.mdを参照し問題を検出。
優先順位（高→低）：
問題ごとの解決策はreferences/analysis-patterns.mdを参照。
段階的な移行計画を作成：
### Phase 1: 準備
- [ ] テストカバレッジ確認
- [ ] 依存関係マップ作成
### Phase 2: 構造変更
- [ ] 新ディレクトリ作成
- [ ] ファイル移動
- [ ] インポートパス更新
### Phase 3: 検証
- [ ] テスト実行
- [ ] ビルド確認
ユーザー: 「auth/モジュールが肥大化している」
auth/
├── mod.rs (800行) ← 神モジュール検出
├── jwt.rs
├── oauth.rs
└── session.rs
問題: mod.rsに認証ロジック、ミドルウェア、エラー型が混在
# パッケージ構造分析レポート
## 検出された問題
1. **神モジュール**: auth/mod.rs (800行、3責務)
## 改善提案
### 提案1: 責務分離
- Before: auth/mod.rs に全ロジック
- After:
- auth/core.rs (認証ロジック)
- auth/middleware.rs (ミドルウェア)
- auth/error.rs (エラー型)
- 理由: 単一責任の原則適用、変更影響範囲の限定
## 移行計画
### Phase 1: 準備
- [ ] 既存テストの確認
### Phase 2: 分割
- [ ] auth/core.rs 作成、ロジック移動
- [ ] auth/middleware.rs 作成
- [ ] auth/error.rs 作成
- [ ] mod.rs を再エクスポートのみに
### Phase 3: 検証
- [ ] cargo test
- [ ] cargo clippy
このスキルを使用する際は、以下のスキルも併せて参照すること：
package-design: リファクタリングの目標となるパッケージ設計原則ddd-module-pattern: DDD文脈でのリファクタリング目標構造intent-based-dedup: リファクタリング時の重複コード共通化判断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はインターフェースアダプタ層に配置すべき という原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。