fraktor-rs

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 スキルを参照。

fraktor-rsのモジュール・型設計を「Less is more」「YAGNI」の観点でレビューし、過剰設計を検出する。参照実装（pekko/protoactor-go）との比較、定量分析、公開範囲の最適化を行う。トリガー：「型の設計をレビューして」「過剰設計チェック」「YAGNIチェック」「ファイル統合」「公開範囲を見直して」「type review」「overengineering check」等の型設計レビューリクエスト時に使用。

Extract project-specific coding rules and domain knowledge from existing codebase, generating markdown documentation for AI agents. Use when onboarding a new project, after code review discussions about coding style, or when coding conventions need documenting. Also consider running after sessions where coding preferences were discussed or corrected (--from-conversation), or after PRs with significant review feedback (--from-pr).

DDDにおけるリポジトリの設計ルールとアンチパターンを提供する。集約単位の命名規則、 CQS（Command Query Separation）に基づくメソッド設計、入出力の型制約をチェックする。 コードレビュー、新規実装、リファクタリング時にリポジトリ設計の問題を検出する場合に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「リポジトリの設計をレビュー」「Repository名がおかしい」「findByIdの戻り値」 「リポジトリがDTOを返している」「テーブル名でリポジトリを作ってしまった」 「集約単位のリポジトリ」「リポジトリのアンチパターン」「リポジトリのCQS」 といったリポジトリ設計関連リクエストで起動。