菜单
既存コードベースのパッケージ/モジュール構造を分析し、リファクタリングを実行する。 循環依存の検出・解消、神モジュールの分割、責務分離の実施、移行計画の作成と実行を行う。 トリガー：「この依存関係を整理して」「循環依存を解消して」「このモジュールを分割して」 「リファクタリングして」といった既存コードの構造改善実行リクエストで起動。 設計指針が必要な場合は package-design スキルを参照。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Kiro / SDD の新規 spec 作成、kiro-discovery、kiro-spec-init、要件化、 仕様化、feature brief 作成に進む前に使う入口スキル。ユーザーの要求を そのまま kiro-* 系スキルへ渡さず、先に grill-with-docs で用語・境界・ 不可逆な設計判断を詰め、必要に応じて CONTEXT.md と docs/adr/* に残してから kiro-discovery または kiro-spec-init へつなぐ。新しい作業の相談、曖昧な feature idea、Kiro spec の起票、requirements 化の依頼では、ユーザーが 明示的に grilling を省略すると言わない限りこのスキルを使うこと。既存 spec の status 確認、requirements/design/tasks/impl の継続、単純な実装、 既に十分な brief.md がある作業では使わなくてよい。
Kiro / SDD の spec から未登録のユビキタス言語、canonical term、 avoid term、不変条件、境界名、契約名、ADR 候補となる仕様変更を検出し、 domain-modeling / grill-with-docs で確定してから CONTEXT.md と docs/adr/* に反映するスキル。ユーザーが「.kiro/specs を見て未定義語を拾って」、 「Kiro spec から CONTEXT.md を更新して」、「spec の仕様変更を ADR に反映」、 「glossary gap を埋めて」、「ユビキタス言語を逆引きして」などを依頼した 場合に使う。単なる spec status 確認、requirements/design/tasks の生成、 実装、または Kiro に渡す前の要求整理には使わない。
fraktor-rsの指定モジュール（actor / stream / remote / cluster / persistence / utils などの論理名）と Apache Pekkoの参照実装を比較し、 不足機能を洗い出すギャップ分析スキル。公開API・trait・オペレーター・パターンを両側から抽出し、 カテゴリ別に分類して難易度を付与する。APIレベルのギャップが少ない場合は、内部モジュール構造 （責務分割・層配置・依存方向）の差分も分析する。 トリガー：「Pekkoと比較して不足機能を洗い出して」「gap analysis」「ギャップ分析」 「references/pekkoとの差分」「不足オペレーターを調べて」「Pekko対応状況」 「modules/{name}の不足機能」といったPekko参照実装との比較リクエストで起動。
fraktor-rsの規約（7つのDylint lint）に沿った新規モジュール・型の雛形を生成する。no_std/std分離、テスト配置、FQCN import、1ファイル1型を自動適用。トリガー：「新しいモジュールを作りたい」「型を追加したい」「ファイル構造を作って」「new module」「モジュール追加」「構造体を新設」等の新規コード作成リクエスト時に使用。
fraktor-rsの共有型設計を対話的に支援する。&mut self vs &self + 内部可変性の判断、Shared/Handleパターン選択、SharedAccessテンプレート生成を行う。トリガー：「共有型を作りたい」「Sharedパターン」「内部可変性」「&mut selfか&selfか」「Shared型を新設」「SharedLock」「SharedRwLock」「shared design」「共有ラッパー」等の共有型設計リクエスト時に使用。
fraktor-rsのモジュール・型設計を「Less is more」「YAGNI」の観点でレビューし、過剰設計を検出する。参照実装（pekko/protoactor-go）との比較、定量分析、公開範囲の最適化を行う。トリガー：「型の設計をレビューして」「過剰設計チェック」「YAGNIチェック」「ファイル統合」「公開範囲を見直して」「type review」「overengineering check」等の型設計レビューリクエスト時に使用。
| 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: リファクタリング時の重複コード共通化判断