메뉴
fraktor-rsのモジュール・型設計を「Less is more」「YAGNI」の観点でレビューし、過剰設計を検出する。参照実装（pekko/protoactor-go）との比較、定量分析、公開範囲の最適化を行う。トリガー：「型の設計をレビューして」「過剰設計チェック」「YAGNIチェック」「ファイル統合」「公開範囲を見直して」「type review」「overengineering check」等の型設計レビューリクエスト時に使用。
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」「共有ラッパー」等の共有型設計リクエスト時に使用。
既存コードベースのパッケージ/モジュール構造を分析し、リファクタリングを実行する。 循環依存の検出・解消、神モジュールの分割、責務分離の実施、移行計画の作成と実行を行う。 トリガー：「この依存関係を整理して」「循環依存を解消して」「このモジュールを分割して」 「リファクタリングして」といった既存コードの構造改善実行リクエストで起動。 設計指針が必要な場合は package-design スキルを参照。
| name | reviewing-fraktor-types |
| description | fraktor-rsのモジュール・型設計を「Less is more」「YAGNI」の観点でレビューし、過剰設計を検出する。参照実装（pekko/protoactor-go）との比較、定量分析、公開範囲の最適化を行う。トリガー：「型の設計をレビューして」「過剰設計チェック」「YAGNIチェック」「ファイル統合」「公開範囲を見直して」「type review」「overengineering check」等の型設計レビューリクエスト時に使用。 |
モジュール・型の設計を「Less is more」「YAGNI」の観点でレビューし、過剰設計を検出・改善提案する。
レビュー対象を確認する：
対象ディレクトリに対して以下を計測する：
# ファイル数・行数（テストファイル除外）
find <target> -name "*.rs" ! -name "tests.rs" ! -name "*_test.rs" ! -name "*_tests.rs" | wc -l
find <target> -name "*.rs" ! -name "tests.rs" ! -name "*_test.rs" ! -name "*_tests.rs" -exec wc -l {} + | sort -n
# 30行以下のファイル数（基準値テーブルの「30行以下ファイル率」に対応）
find <target> -name "*.rs" ! -name "tests.rs" ! -name "*_test.rs" ! -name "*_tests.rs" -exec wc -l {} + | awk '$1 <= 30 {count++} END {print count}'
# 公開型の数
grep -r "^pub struct\|^pub trait\|^pub enum" <target> --include="*.rs" | wc -l
基準値（Phase 1-4 の実績から導出）:
| 指標 | 正常 | 要注意 | 過剰 |
|---|---|---|---|
| 30行以下ファイル率 | < 20% | 20-35% | > 35% |
| 平均行数/ファイル | > 80行 | 50-80行 | < 50行 |
| pub 型 vs pub(crate) 型比率 | 外部利用に応じた比率 | - | pub が大半 |
対象と同等の機能を持つ参照実装の型数を確認する：
references/pekko/): Scala の対応クラス数を調査references/protoactor-go/): Go の対応型数を調査fraktor-rs の型数 / 参照実装の型数 = 倍率
倍率 1-2x: 正常（Rust の所有権・ライフタイム要件で型が増えるのは自然）
倍率 2-3x: 要注意（no_std/std 分離や Shared 型を差し引いても多い可能性）
倍率 3x+: 過剰（設計見直し推奨。Phase 1-4 で message_adapter が 6.5x → 統合で改善した実績あり）
以下のパターンを探す：
pub だが crate 外から参照されていない型検出した問題に対して具体的な改善案を提示する：
| 問題 | 改善案 |
|---|---|
| 薄い型の過剰分離 | 親型と同居（ただし同居先200行以下） |
| 型の重複 | 統合して単一型に |
| 不要な公開 | pub(crate) に変更 |
| 過剰な抽象化 | 具体型に簡素化 |
mcp__serena__find_referencing_symbols で各公開型の参照元を調査し、以下に分類：
リクエスト: 「tick_driver の型を見直したい」
定量分析結果:
参照実装比較:
検出パターン:
TickDriverId(u64): 20行、独立ファイル → newtype は維持（ドメインプリミティブ）HardwareKind: 再エクスポートのみ、直接参照なし → 削除候補TickMetricsMode: 22行、TickDriverConfig でのみ使用 → pub(crate) 化候補改善提案:
リクエスト: 「ClusterMembership の設計をレビューして」
参照実装比較:
判定: 3倍超 → 設計の簡素化を推奨
claudedocs/actor-module-overengineering-analysis.md: Phase 1-4 の分析基準と実績。基準値テーブルの根拠や過去の改善事例を確認する際に参照references/pekko/: Scala 参照実装。ステップ3 で対応クラス数を調査する際に参照references/protoactor-go/: Go 参照実装。ステップ3 で対応型数を調査する際に参照