github-pull-request
GitHub Pull Request
AIに実装させた変更を抽象度の階層構造で分析し、人間が機微を即座に知覚できるGitHub PR本文を生成する。
原則
- 大きい地図から具体へ。 抽象→具体を基本順序とする。ただし変更が小規模な場合や、読者にとって逆順が自然な場合は柔軟に構成を選べ
- 図と表で語れ。 長文の説明より、Mermaid図とテーブルが優先
- 内部では疑って検証し、出力では事実を伝える。 分析プロセスは厳しく、PR本文は冷静に
- セクションはAIが判断する。 変更に関係ないセクションは出力しない（ただしrequireは常に）
- ゴールデンサークルを思考の指針に。 Why（なぜ必要か）→ How（どう解決したか）→ What（何を変更したか）の順で考えよ。ただし出力の形式やテンプレートとして固定するな。状況に応じた最適な構成を選ぶこと
- 前提知識ゼロで読めるように。 専門用語は補足を添え、文脈が独立して完結するように書け
タイトルガイド
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向け大規模一貫変更を提供。ローカル開発完了後のリファクタリング時に使用。
21module-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 が必要か判断して』といった場面で使用する。
17database-design
DB のテーブル・カラム命名を、処理目的ではなく永続化する概念・entity・関係から判断するためのスキル。DB命名、スキーマ命名、正規化に伴う命名、用途に過適合した名前を避けるときに使用する。
12