efoo-team

@efoo-team source repo

34 skills
0 followers
6 hours ago last updated

▌
Pr · efoo-team bundle
Only use when the user explicitly invokes /pr (or $pr in Codex). Never auto-invoke. フィーチャーブランチの作成からステージング・コミット・push・Pull Request 作成までの一連の Git 操作を、ブランチ運用ルール（develop 優先・保護ブランチへの直接コミット禁止）を遵守しながら安全に実行する。

0
installs
▌
Ask · efoo-team bundle
Only use when the user explicitly invokes /ask (or $ask in Codex). Never auto-invoke. 質問に対して、実装や編集を一切行わず、事実に基づく分析と回答を提供する read-only スキル。コードの仕組み・実装方針・エラー原因・設計妥当性などの質問に、推測ではなく実装とドキュメントの事実に基づいて回答する。

0
installs
▌
Define · efoo-team bundle
Only use when the user explicitly invokes /define (or $define in Codex). Never auto-invoke. 実装前の詳細な要件定義を行うためのスキル。プロジェクトの新機能や改修について、ユーザーと要求・要件の共通認識を確立し、技術的制約・設計方針・実装仕様を定義して実装の方向性を明確化する。ソースコードの実装は行わず、成果物として要件定義書（Markdown）のみを出力する。

0
installs
▌
Oracle · efoo-team
Runs Oracle CLI in ChatGPT browser mode to ask an external cloud model for high-level reasoning, decomposition, review, or final evaluation. Use when an agent needs a second model to analyze complex tradeoffs, check a plan, evaluate a diff, debug a hard issue, or surface missing assumptions. Treat every Oracle run as a stateless, standalone request and send the prompt and required files explicitly because Oracle cannot access local machine resources or prior Oracle-run context unless they are provided.

0
installs
▌
Execute · efoo-team bundle
Only use when the user explicitly invokes /execute (or $execute in Codex). Never auto-invoke. 複雑なタスクを整理・分割し、利用可能な委譲機構を統括してプロジェクトを遂行するオーケストレーションスキル。実装詳細よりも全体の整理・統括に注力し、タスクの依存関係を整理して独立したタスクは並列に委譲する。『タスクを実行して』『まとめて遂行して』『オーケストレーションして』といった明示的な起動時に使用する。

0
installs
▌
Pr Body · efoo-team bundle
Only use when the user explicitly invokes /pr-body (or $pr-body in Codex). Never auto-invoke. AIに実装させた変更を抽象度の階層構造で分析し、構造化されたGitHub PR本文として出力する（本文生成のみ。Git操作は行わない。旧名 github-pull-request）。大規模変更でも、システム構成図→データ構造→API→処理フロー→実装詳細の順で抽象→具体へ整理する。画像エビデンスを含むPR本文の組み立て方も扱う。

0
installs
▌
Pr Stage · efoo-team bundle
Only use when the user explicitly invokes /pr-stage (or $pr-stage in Codex). Never auto-invoke. 既にステージ済み（git add 済み）の変更だけをコミットし、必要ならフィーチャーブランチ作成・push・PR 作成まで行う。手順と安全ガードの正本は pr スキルにあり、本スキルはその差分（ステージ済み変更のみを扱う）だけを定義する薄型ラッパー。

0
installs
▌
Pre Define · efoo-team bundle
Only use when the user explicitly invokes /pre-define (or $pre-define in Codex). Never auto-invoke. ユーザーの曖昧な要望を、詳細な要件定義（/define）に渡せる具体的な入力へ洗練させるためのスキル。仕様決定や要件定義そのものは行わず、関連する既存仕様を調査したうえで平易な質問を重ね、コミュニケーションの齟齬をなくすことを目的とする。

0
installs
▌
Skill Memo · efoo-team bundle
Only use when the user explicitly invokes /skill-memo (or $skill-memo in Codex). Never auto-invoke. エージェントの推論・挙動について気づいた課題や、残しておきたい知見を efoo-team/skills の GitHub issue へ記録するスキル。記録先は efoo-team/skills 固定で、同じ課題の既存 issue があれば再発としてコメント追記する。プロダクトの不具合・要望を各プロジェクトのリポジトリへ起票するのは issue-report-dev / issue-report-user の役割であり、本スキルはスキル・指示ファイルの改善材料の蓄積に限る。

0
installs
▌
Review Plan · efoo-team bundle
Only use when the user explicitly invokes /review-plan (or $review-plan in Codex). Never auto-invoke. 実装前の計画や作業計画を、独立した複数のレビュー観点（委譲機構が利用可能ならレビュー用サブエージェント）で厳密レビューし、レビュー→妥当性確認→採否決定→採用指摘の計画文書への反映提案を最低3サイクル実行する。計画文書本体の直接編集とソースコード実装は行わず、改訂提案はチャットで提示する。

0
installs
▌
Create Skill · efoo-team bundle
Only use when the user explicitly invokes /create-skill (or $create-skill in Codex). Never auto-invoke. 新しい Agent Skill をゼロから対話的に作成するためのスキル。「スキルを作りたい」「この作業をスキル化したい」という場面で使用する。ユーザーへの質問で意図（解決したい課題・発火してほしい場面・利用範囲）を見極めてから、スキル化の要否判定、配置層（共通層/プロジェクト層）と名前の決定、SKILL.md の設計・執筆、チェッカーでの検証までを一貫して行う。スキル執筆の一般原則（progressive disclosure・description 執筆等）の正本は agent-native-project-design にあり、本スキルはそれを適用する作成ワークフローを提供する。

0
installs
▌
Plan Explain · efoo-team bundle
Only use when the user explicitly invokes /plan-explain (or $plan-explain in Codex). Never auto-invoke. `.sisyphus/plans/` 配下などの計画ファイルを読み込み、その計画が何を行うものかを人間が即座に把握できる構造化された概要説明レポートを生成する。事実抽出のみを行い、解釈・推測・追加調査は行わない。

0
installs
▌
UI UX Design · efoo-team bundle
UI・画面・導線の設計判断を行うスキル。新規画面や機能追加時のUI設計・アクション配置、既存UIの整理・シンプル化、要件段階の画面遷移・情報設計、UI設計レビューで、「UIを設計して」と明示されなくても使う。検討手順（オブジェクト→構造→フロー→データ状態→UI）と、入口統合・段階的開示・配置の判断基準を提供する。色・タイポグラフィ等ビジュアル表現の作り込みは対象外。コードの境界設計は module-boundary-design、API 設計は restful-api-design を使う。

0
installs
▌
Agents Md Sync · efoo-team bundle
Only use when the user explicitly invokes /agents-md-sync (or $agents-md-sync in Codex). Never auto-invoke. リポジトリ全体を解析し、階層ごとの AGENTS.md 知識ベース（ルートと、スコアリングで選定したサブディレクトリ）を生成・更新するスキル。実行のたびに既存 AGENTS.md とコードベースの乖離を検出して最新状態に追従させ、Claude Code 用の CLAUDE.md ブリッジも維持する。初回作成時は、コードから導出できない規範情報（目的・開発フェーズ・運用制約）をヒアリングで補う。AGENTS.md の整備・初期化・更新や init-deep 相当の知識ベース構築を求められたときに使用する。指示ファイルに何を書くべきかの設計原則は agent-native-project-design を参照する。

0
installs
▌
Search History · efoo-team bundle
Only use when the user explicitly invokes /search-history (or $search-history in Codex). Never auto-invoke. Claude Code / Codex CLI のローカルチャット履歴（JSONL）をキーワードで横断検索し、該当するセッションと会話断片を提示する。履歴ファイルは読み取り専用で扱う。

0
installs
▌
Cleanup Storage · efoo-team bundle
Only use when the user explicitly invokes /cleanup-storage (or $cleanup-storage in Codex). Never auto-invoke. ローカルマシンのストレージ逼迫を解消するスキル。ディスク使用量を調査し、削除候補を安全度カテゴリ順に整理して提示し、カテゴリごとにユーザー承認を得てから削除し、空き容量の変化を報告する。

0
installs
▌
Database Design · efoo-team
DB のテーブル・カラム命名を、処理目的ではなく永続化する概念・entity・関係から判断するためのスキル。DB命名、スキーマ命名、正規化に伴う命名、用途に過適合した名前を避けるときに使用する。

0
installs
▌
Review Pr Check · efoo-team bundle
Only use when the user explicitly invokes /review-pr-check (or $review-pr-check in Codex). Never auto-invoke. PRレビュー対応を収集ワーカー・分類サブエージェント・実行ワーカーへ分離してオーケストレーションするスキル。収集は gh pr-review-check を実行する収集ワーカーに、分類・グループ化・ワークパケット生成は分類サブエージェント（デフォルト例は Oracle）に、実装・返信・resolve などの実作業は実行ワーカーに委譲し、parent は完全性ゲート・fallback 起動・ポーリングループを管理する。サブエージェント機構が無い環境では parent 自身が縮退実行する。

0
installs
▌
Dependabot Sweep · efoo-team bundle
Only use when the user explicitly invokes /dependabot-sweep (or $dependabot-sweep in Codex). Never auto-invoke. Dependabot が作成した依存関係更新 PR を一括で分析し、すべての更新を 1 つのブランチに統合した単一 PR を作成する。各 dependabot PR を個別マージせず統合 PR にまとめ、元の PR はコメントを残してクローズする。

0
installs
▌
Issue Report Dev · efoo-team bundle
Only use when the user explicitly invokes /issue-report-dev (or $issue-report-dev in Codex). Never auto-invoke. エンジニア自身が書く GitHub issue の起票スキル。ログ・スタックトレース・失敗テストを取り込み、サブエージェントでファイル/シンボル単位まで根本原因を調査し、原因の仮説・修正方針案・受入条件まで含む issue を起草する。技術的な質問と期待仕様の確認を制限なく行い、想定変更領域の重なりでグルーピングして登録・統合する。非エンジニアからの報告受付は issue-report-user を使う。

0
installs
▌
Orca Automations · efoo-team bundle
Only use when the user explicitly invokes /orca-automations (or $orca-automations in Codex). Never auto-invoke. Orca の自動化（Automations）を orca CLI で作成・管理するスキル。「毎朝9時に◯◯して」「定期実行・スケジュール実行する automation を作って」「自動化の一覧・実行履歴・削除」を Orca 利用環境で求められたときに使用する。フラグ仕様はインストール済み CLI への問い合わせに委譲し最新仕様に追従する。OS の cron・CI のスケジュール・Claude Code 自身の定期実行には使わない。

0
installs
▌
Refactor Mindset · efoo-team
リファクタリング（構造・境界・契約の再設計を含む）の要否と進め方を、変更容易性を高める方向で判断するスキル。ローカル開発完了後に「リファクタリングして」「整理して」「きれいにして」と言われたとき、コードが理解・保守しにくいとき、Code Smell への対処が必要なときに使用する。境界の引き方・責務配置の詳細判断は module-boundary-design を使う。

0
installs
▌
Estimate Proposal · efoo-team bundle
受託開発の概算見積と、客先提出用の見積書兼提案書を作成するスキル。Only use when the user explicitly invokes /estimate-proposal (or $estimate-proposal in Codex). Never auto-invoke. 現行システム・議事録・RFP などから機能を棚卸しし、踏襲/改良/新規/統合/廃止の方針を判定し、粒度を機能単位へ正規化してからポイント積算し、機能一覧スプレッドシートと Google Docs の見積書まで生成する。受注後の実装向け詳細要件定義は define を使う。

0
installs
▌
Issue Report User · efoo-team bundle
Only use when the user explicitly invokes /issue-report-user (or $issue-report-user in Codex). Never auto-invoke. 非エンジニアの報告者から不具合報告や機能要望を複数まとめて受け付け、ケースごとにサブエージェントで並列調査し、想定変更領域の重なりでグルーピングして GitHub issue を新規登録・既存 issue へ統合するスキル。並列ワークツリー開発でコンフリクトしない単位に issue を編成することを目的とする。平易な言葉だけでヒアリングし、登録計画の承認を得てから gh CLI で書き込む。解決策・実装仕様の決定は行わない。エンジニア自身が起票する場合は issue-report-dev を使う。

0
installs
▌
SQL Writing Style · efoo-team
SQLを書くときに使用する。読み手が一瞥して理解できるSQLを書くためのスタイルルール。

0
installs
▌
Documentation Sync · efoo-team
コード変更に伴うドキュメントの整合性を検証・同期するためのスキル。git diff から変更カテゴリを分類し、カテゴリ別にドキュメント同期の要否を判定し、自動生成ドキュメントを再生成し、リンク切れを確認し、表形式で報告する。ドキュメント同期、ドキュメント整合性確認、更新漏れ検出が必要なときに使用する。AGENTS.md 階層の生成・更新そのものが主題のときは agents-md-sync（明示起動）を使う。

0
installs
▌
Formation Designer · efoo-team bundle
oh-my-openagent (formerly 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.

0
installs
▌
Restful API Design · efoo-team bundle
Web API / HTTP API の設計判断を行うためのスキル。リソース設計、URL、HTTP メソッド、ステータスコード、表現形式、エラー、ページネーション、互換性、バージョニング、セキュリティ、破壊的変更の判断が必要なときに使用する。

0
installs
▌
Agent Prompt Design · efoo-team
AIエージェントに与えるプロンプト・instructions・システムプロンプト・委譲文・スキルや指示ファイルの文面を書く/直す/レビューするときの執筆原則。エージェントサービスやスキルの指示文を設計する場面で、明示されなくても使用する。記述高度・既習概念の指名・工程とメンタルモデルの切替・モデル進化を享受する記述を扱う。SKILL.md の規約や発火設計は agent-native-project-design、コンテキスト機構やハーネス設計は agent-harness-engineering を参照。

0
installs
▌
Mastra Framework Guide · efoo-team bundle
Mastra フレームワークの API 検証・最新ドキュメント探索・バージョン移行のガイド。Mastra のコードを書く前の現行仕様確認、API シグネチャの検証、agent / workflow / tool / memory / RAG の構築、v0.x → v1.x などの移行で使用する。内部知識は古い前提とし、必ずインストール済みバージョンの型定義か公式ドキュメントで検証すること。責務分離などの設計判断は mastra-ai-architecture-rules を使う。

0
installs
▌
Module Boundary Design · efoo-team bundle
機能境界・責務分離・モジュール分割・抽象化の設計判断を行うスキル。どこで境界を切るか、責務をどう分けるか、抽象化が妥当か、責務配置を見直したいときに使用する。単純な CRUD 追加・差分レビュー・API 表面設計には使わない。リファクタリング全般の判断は refactor-mindset を使い、境界の引き方・責務配置が主題のとき本スキルを使う。

0
installs
▌
Agent Harness Engineering · efoo-team bundle
AIエージェントのハーネス（エージェントループ・ツール表面・コンテキスト管理・認可・状態・停止条件・評価・可観測性）を設計・実装・調達するためのランタイム非依存の設計憲章。『エージェント基盤/ハーネスを設計して』『自作/SDK/既製のどれにするか』『compactionをどうするか』『マルチエージェントにすべきか』という場面で使用する。リポジトリ側の設計は agent-native-project-design、Mastra 上の設計は mastra-ai-architecture-rules を参照。

0
installs
▌
Agent Native Project Design · efoo-team bundle
Claude Code / Codex 等の既製AIエージェント・ハーネス上で運用するリポジトリ/プロジェクト側（CLAUDE.md / AGENTS.md・Agent Skills・hooks・subagents）を設計・整理・刈り込みするスキル。『CLAUDE.mdを設計/整理して』『この作業をエージェントに任せたい』『スキルを作りたい』『エージェントが指示を守らない』という相談で使用する。ハーネス/ランタイム自体の開発は agent-harness-engineering を参照。

0
installs
▌
Mastra AI Architecture Rules · efoo-team bundle
Mastra をランタイムとする AI サービスの設計・実装・リファクタリングで、agent / workflow / tool / memory / state の責務分離と、LLM に任せる範囲と決定的コードの境界を判断するスキル。『Mastra で設計して』『workflow を作って』『state に何を持つべきか』『memory や workspace が必要か』で使用し、single-agent first・workflow 最小化を適用する。現行 API 仕様の確認・検証・バージョン移行は mastra-framework-guide を使う。

0
installs

34 published skills