module-boundary-design
モジュール境界設計スキル
機能の境界をどこに引き、何を同じ側に置き、何を分けるかを判断するための思考手順。
原則
機能境界は 処理の順序 ではなく 変更理由の独立性 で決まる。
そしてもう一つ。境界を「引く」だけでは不十分で、その境界を「成立させる」必要がある。責務を分けただけでは境界にはならない。境界が意味を持つのは、公開面・状態の所有・依存方向・不変条件の守備範囲が明確になったときである。
適用範囲
More from efoo-team/skills
langfuse
Query, debug, and analyze LLM observability data from Langfuse via REST API. Covers traces, observations, sessions, scores, prompts, and datasets. Use when investigating agent behavior, debugging LLM calls, analyzing costs/latency, reviewing prompt versions, or auditing Mastra agent runs.
22formation-designer
oh-my-opencode formation (agent-model configuration) design and creation guide. Use when creating new formations, modifying existing formations, adding new providers/models, or reviewing formation design decisions. Covers multi-axis model classification (Reasoning, Cost, Speed, Instruct, Style, Multimodal), agent-model matching principles, naming conventions, and cost optimization strategy.
22refactor-mindset
構造と意図の整合をとり、変更容易性を高める。局所最適化された設計を将来の変更を見据えた構造へ再構築する。Code Smellの仮説的扱い、AI向け大規模一貫変更を提供。ローカル開発完了後のリファクタリング時に使用。
21mastra-ai-architecture-rules
Mastra をランタイムとする AI サービスの設計・実装・リファクタリング時に使用する。agent / workflow / tool / workspace / memory / RequestContext / workflow state / 永続ストレージの責務分離を定義し、LLM に任せる範囲と決定的なコードに落とす範囲を判断する。single-agent first、workflow 最小化、state には参照・ID・要約のみを保持する原則、optional capability（workspace・memory・永続ストレージなど）は必要性が確認できた場合のみユーザー承認後に導入する原則を適用する。『Mastra で設計して』『workflow を作って』『agent と code の境界を決めて』『state に何を持つべきか整理して』『memory や workspace が必要か判断して』といった場面で使用する。
17github-pull-request
AIに実装させた変更を抽象度の階層構造で分析し、構造化されたGitHub PR本文として出力する。大規模変更（1万行超）でも、システム構成図→データ構造→API→処理フロー→実装詳細の順で抽象→具体へ整理する。画像エビデンスを含むPR本文の組み立て方も扱う。「PR本文を書いて」「この変更をPRにする」「実装した内容のPRを作りたい」といった場面で使用する。
13database-design
DB のテーブル・カラム命名を、処理目的ではなく永続化する概念・entity・関係から判断するためのスキル。DB命名、スキーマ命名、正規化に伴う命名、用途に過適合した名前を避けるときに使用する。
12