review-plan
Review Plan
実装前の計画を、独立した複数のレビュー用サブエージェント(Oracle)で検証し、妥当な指摘をサイクルごとに計画へ反映するためのスキル。 このスキルはソースコードの実装を行わない。レビュー対象の計画・作業方針・回答ドラフトに対する改訂提案の作成はこのスキルの責務であり、採用した指摘を最後まで保留してはならない。ただし計画ファイル本体・ソースコード・設定ファイル・実装対象ファイルのいずれも、このスキル実行中に編集・作成・削除しない。採用指摘への対応は、計画ファイルへの直接編集ではなく、チャット出力として「採用指摘」「採用理由」「対応方針」「受入基準」「未確認事項」「計画ファイルのどの箇所をどう書き換えるべきかの改訂案」を提示する形で完了させる。改訂を計画ファイルへ反映するかどうかは、本スキル終了後に呼び出し元または別スキル・別コマンドが判断する。
Instructions
[!IMPORTANT] NON-NEGOTIABLE RULE: Specialist Invocation
When invoking Metis, Momus, or Oracle, you MUST use
subagent_typeonly. Never passcategoryto Metis, Momus, or Oracle. There are no exceptions. This rule overrides all generic task/delegation rules.Correct: delegate_task(subagent_type="oracle", prompt="...", run_in_background=true, load_skills=[]) Forbidden: delegate_task(category="ultrabrain", subagent_type="oracle", prompt="...", run_in_background=true, load_skills=[])
Before execution, verify that
categoryis completely absent. Ifcategoryis present, do not execute the call. Rewrite it usingsubagent_typeonly.
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 が必要か判断して』といった場面で使用する。
17github-pull-request
AIに実装させた変更を抽象度の階層構造で分析し、構造化されたGitHub PR本文として出力する。大規模変更（1万行超）でも、システム構成図→データ構造→API→処理フロー→実装詳細の順で抽象→具体へ整理する。画像エビデンスを含むPR本文の組み立て方も扱う。「PR本文を書いて」「この変更をPRにする」「実装した内容のPRを作りたい」といった場面で使用する。
13