refactor-mindset
Refactoring
構造と意図の整合をとり、変更容易性(changeability)を高める。 リファクタリングの目的は、将来の変更コストを下げること。それ以外にない。
詳細なコーディングルールではなく、「まともなエンジニアなら理解している良いコードとは何か」にフォーカスする。
前提: ローカル開発状態
このスキルの対象は、開発完了後でまだステージング・プロダクションに反映されていないコードである。 外部への影響を気にせず、構造をあるべき姿に大胆に合わせられる。
使用時期
- コードが理解しにくい、または保守しにくい場合
- 関数・クラスが大きすぎる場合
- Code Smellに対処が必要な場合
- コード構造のせいで機能追加が困難な場合
- ユーザーが「コードをきれいにして」「リファクタリングして」「改善して」と求めた場合
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.
22module-boundary-design
ソフトウェアの機能境界・責務分離・モジュール分割・抽象化の設計判断を行うためのスキル。設計相談を受けたときの内部思考プロセスとして使用する。「この機能をどう設計すべきか」「責務をどう分けるか」「リファクタリングしたい」「モジュール分割を考えたい」「抽象化が正しいか判断したい」「クラス設計を見直したい」「コードの見通しが悪い」「何をどこに置くべきか」といった設計構造に関する相談全般で必ずこのスキルを参照すること。設計レビュー、アーキテクチャ検討、コード構造の改善提案にも適用される。
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