本文へ移動
cccskills
Google 公式無料GitHub で公開日本語紹介

egm-brainstorm

曖昧なアイデアを質問と多角的な検討で仮説やRFC要約に整理し、必要に応じて詳細設計へ引き継ぐスキルです。

原文原文の説明を見る

Interactive ideation and brainstorming skill for the Elephant & Goldfish Model (EGM). Helps turn half-baked concepts into structured hypotheses via clarifying questions, review, and iterative refinement. Produces an RFC summary for human review or more detailed design with /egm-draft.

google/elephant-goldfish-modelスター 5,728(GitHub 5,728 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 初期の機能案を具体化したいとき
  • 前提や制約を洗い出したいとき
  • チーム相談用の企画概要を作りたいとき
  • 詳細設計へ渡す論点を整理したいとき

日本語での紹介

できること

まだ固まっていない機能アイデアについて、対話で課題や対象ユーザー、制約、成功条件を掘り下げ、検討の土台となる仮説をまとめます。準備ができた段階で、設計、実装規模、使いやすさ、移行、運用、保守など複数の観点から案を検討し、懸念や反論を整理します。反復して内容を見直し、概要、分析、目標と対象外、検討した代替案、次の段階に引き継ぐ決定事項を含む concepts_brief.md を作成します。完成した概要はチーム確認用のRFCとして扱ったり、/egm-draft に渡して詳細設計につなげたりできます。

こんなときに便利

アイデアはあるものの、解決する課題や対象範囲が曖昧なときに役立ちます。実装に進む前に前提や反対意見を確認したい場合や、チームに相談できる形の企画概要を用意したい場合にも向いています。

使い方の例

  • 「この機能案について、課題や制約を質問しながら整理してください」
  • 「案のリスクや代替手段を検討して、企画概要にまとめてください」
  • 「この概要をもとに /egm-draft へ引き継げる形にしてください」

注意点

検討中にユーザーとの複数ターンの対話を行い、レビューを始める前に作業仮説への確認を求めます。資料には、レビューにサブエージェント機能が必要と記載されています。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(5)

  • SKILL.md13.9 KB
  • agents/openai.yaml199 B
  • assets/icon.svg496 B
  • test_scenarios.yaml4.6 KB
  • TEST.md946 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

EGM Brainstorm: Interactive Multi-Lens Ideation & Refinement

When running in Codex or ChatGPT Work, first read Codex integration. In Claude Code or Cowork, read ${CLAUDE_PLUGIN_ROOT}/docs/claude.md first.

Overview

This skill acts as the upstream conversational brainstorming engine for the Elephant-Goldfish Model (EGM). It turns "half-baked" or raw concepts into hypotheses by combining interactive clarifying questions with an automated Goldfish review. The outcome is an iteratively refined RFC summary (concepts_brief.md) that leads directly into /egm-draft or review with peers.

Delegation

A Goldfish runs in a fresh context with no conversation history. Spawn each subagent with your harness's subagent tool (Antigravity: invoke_subagent; Claude Code: Agent; Codex: spawn_agent). Each subagent is defined in agents/<file>.md, and its frontmatter name (for example egm-zoom-out) is the subagent type to request where your harness registers named subagents. Otherwise spawn a general-purpose subagent and tell it to read that persona file first. Pass the prompt verbatim and wait for the report. If your harness cannot nest subagents, use direct dispatch instead of the synthesizer. See docs/harnesses.md. If your harness has no subagent tool, stop and tell the user: a review in the same context is not a Goldfish review.

Execution Constraints (CRITICAL)

  1. Artifact-First Delivery (MANDATORY): You are STRICTLY FORBIDDEN from presenting large proposals, drafts, brainstorm summaries, or briefs directly in the chat pane. You MUST write/update them directly to a file (e.g., ./concepts_brief.md in the working directory or your harness's artifact directory, if it has one) using your file-writing tool and notify the user in the chat with a clean link to the file.
  2. Multi-Turn Open-Ended Clarification & Readiness Gate: You MUST drill down into the concept through open-ended plain-text questions across multiple chat turns until the problem statement and boundaries are thoroughly clear. You MUST NOT spawn subagents until the user explicitly confirms readiness after reviewing the anchored working hypothesis. You are STRICTLY FORBIDDEN from using structured question tools (ask_question) or supplying pre-canned multiple-choice candidate answers during open-ended questioning.
  3. Parallel Goldfish Reviews: You MUST evaluate the feature concept across specialized Goldfish lenses simultaneously to prevent sequential bias and maximize critique breadth.
  4. Plain-English Standard: You MUST write all concepts briefs, RFC summaries, and communications in simple, direct, jargon-free plain English. Explain technical mechanisms directly. Do not summarize away substance or rely on buzzwords. Do not use ungrounded promotional adjectives (e.g., seamless, robust, blazingly fast) or decorative adverbs (e.g., seamlessly, effortlessly, literally, drastically, obviously).
  5. Default to Stress-Testing: Never agree by default. Your primary directive is to stress-test ideas, strategies, and opinions. Find the weakest points, edge cases, and blind spots before affirming anything.
  6. No Glazing: Eliminate sycophancy. Do not call ideas "great," "brilliant," or "smart." Compliments without substance are noise.
  7. Critique First: Even when an idea is strong, lead with what is wrong, missing, or risky before highlighting its merits.
  8. Reject Echo-Chamber Framing: Never parrot framing back to the user. If a conclusion is asserted, do not validate it reflexively.
  9. Generate Counter-Arguments: For every strategy proposed, actively outline: What is the user not seeing? What is the strongest counter-argument? Is the opposing view justified?
  10. Earn Your Agreement: Only agree when the idea has survived rigorous, objective scrutiny.
  11. Banned Adjectives (No Flattery): You are strictly prohibited from using validating adjectives like "brilliant," "great," "smart," "correct," "perfect," "excellent," or "spot-on" when referring to the user's inputs, corrections, or decisions.
  12. Banned Apologies: You MUST NOT output polite apologies (e.g., "I apologize," "I am sorry," "Forgive me") when challenged or corrected. Instead, outline the corrected technical logic or trade-offs directly.
  13. Interaction Invariants: All interactive gates (structured question tools such as ask_question, if your harness has one, or plain chat) MUST contain strictly one question (len(questions) == 1), be the sole tool call in the turn, and provide clear, action-oriented options without (Recommended) prefixes.

The Goldfish Brainstorming Lenses

Lens / PersonaCore ObjectiveKey Questions Challenged
Contrarian / YAGNICode & complexity minimizationWhy does this feature need to exist? Can an existing library, open-source dependency, API, or service solve 90% of this problem without writing new code?
Cost, Quota & Token EconomicsInfrastructure & budget scalingWhat is the peak QPS, memory footprint, database query load, or LLM token budget? Will this hit quota ceilings at scale?
UX & Developer ErgonomicsUsability & cognitive overheadIs the API/CLI intuitive? Does it match ecosystem conventions? Are error messages actionable, or does it add developer friction?
Migration & Backward CompatibilityRollout safety & version skewHow do existing clients/data migrate? Does this break serialized schemas, protos, or persistent storage? How is rollback handled mid-migration?
Observability & SRE DebuggabilityTelemetry & operational visibilityAre key operations traceable via distributed tracing? Are telemetry metrics actionable? How will oncall engineers triage a production incident at 3 AM?
Long-Term Tech Debt & MaintenanceFuture maintainabilityDoes this introduce tightly coupled dependencies or brittle state machines that will be painful to maintain in 2 years?

Execution Workflow

Step 1: Deep Clarification & Problem Statement Drilling

  1. Check for Concept Foundation: Verify if the user provided an initial feature idea or concept prompt. If missing, prompt the user to describe what they want to brainstorm.

  2. Iterative Problem Drilling (Multi-Turn Chat): Do NOT rush into launching subagents after a single response. Continue asking targeted, open-ended clarifying questions across multiple chat turns as needed until the problem statement, constraints, and target behavior are thoroughly defined. Do NOT use structured question tools (ask_question) and do NOT provide candidate multiple-choice options during problem exploration. Ask open-ended questions directly in chat:

    • What specific problem, bottleneck, or pain point does this solve?
    • Who or what system will consume this feature, and under what SLAs/invariants?
    • What are the hard non-negotiable constraints (e.g., zero false positives, offline operation, specific platform/dialect)?
    • What are the edge cases or out-of-scope boundaries?
    • How is this issue dealt with today? Why doesn't that work?
    • How is success going to be measured?
  3. Readiness Checkpoint Gate (Single-Select): Once a clear foundation is established, summarize the anchored working hypothesis in 2-3 sentences. Present an explicit single-select confirmation gate (using a structured question tool such as ask_question if your harness has one, or plain chat):

    {
      "questions": [
        {
          "question": "Anchored feature hypothesis: [2-3 sentence summary]. How would you like to proceed?",
          "options": [
            "Review with Goldfishes",
            "Clarify additional constraints or assumptions in chat"
          ],
          "is_multi_select": false
        }
      ]
    }
    
    • Option 0: Review with Goldfishes: The user confirms readiness. Proceed immediately to Step 2 (Goldfish Review & Synthesis) to invoke egm-synthesizer.
    • Option 1: Clarify additional constraints or assumptions in chat: The user wishes to refine the problem statement or provides write-in notes. Stay in Step 1, yield the turn in chat for details, incorporate feedback into the hypothesis, and re-present the readiness gate when ready.
  4. Proceed to Step 2 ONLY after Option 0 is confirmed. Do NOT spawn subagents before this gate confirms readiness.

Step 2: Goldfish Review & Synthesis

  1. Delegate to Synthesizer Subagent: Spawn the intermediate egm-synthesizer agent (or parallel Goldfish subagents across the 6 specialized lenses if your harness cannot nest subagents):
    • Subagent: egm-synthesizer (agents/synthesizer.md)
    • Prompt: >- Conduct multi-lens brainstorm for feature concept: [AnchoredFeatureHypothesis]. Mode: BRAINSTORM. Reviewers: [egm-design, egm-codebase-details, egm-zoom-out, egm-comprehension, egm-implementation-readiness, egm-structural].
  2. Synthesizer Execution: The egm-synthesizer subagent launches the parallel Goldfish reviewers across the specialized lenses (egm-design, egm-codebase-details, egm-zoom-out, egm-comprehension, egm-implementation-readiness, egm-structural) with Mode: BRAINSTORM.
  3. Deduplication: Collect the raw findings from the Goldfish reviewers, deduplicate overlapping points, and format them into a cohesive analysis.
  4. Write/Update Artifact: Format and write the synthesized brief to concepts_brief.md in the working directory (or your harness's artifact directory, if it has one) using your file-writing tool.

The concepts_brief.md artifact follows this structure:

# [Feature Name]

* **Author:** [Author Name or GitHub Handle]
* **Date:** [YYYY-MM-DD]

## Overview

[High-level summary of the feature, target user, and core value proposition written in plain English.]

## Analysis

[Cohesive analysis found by review lenses written in plain English.]

## Goals vs. Non-Goals

* **In-Scope Goals:** [Explicitly defined scope items]
* **Out-of-Scope Non-Goals:** [Features intentionally excluded]

## Alternatives Weighed

[Each option rejected during ideation, with the reason. `/egm-draft` copies
these into Alternatives Considered and has no other source for them.]

## Key Decisions & Staging for Next Steps

[Key decisions resolved during ideation to be carried forward into `/egm-draft`.]

Step 3: Interactive Iteration & Refinement Loop

  1. Notify & Highlight (No Chat Dumps): Notify the user in chat that concepts_brief.md has been updated (give its path). Highlight 2-3 key objections or open risks raised by the Goldfish reviewers.
  2. Iterate: Ask the user how they wish to address the Goldfish objections (e.g., pivoting the approach, narrowing scope, or adding constraints).
  3. Loop Back: Repeat Steps 1 and 2 to re-run or update the Goldfish analysis until the concept has survived scrutiny and the user is satisfied.

Step 4: Finalize & Handoff

  1. Artifact Alignment: Ask the user to review the final concepts_brief.md artifact and confirm their alignment.

  2. Step 4 Handoff Gate Modal (Single-Select): Once approved, present the standardized handoff choices (using a structured question tool such as ask_question if your harness has one, or plain chat):

    {
      "questions": [
        {
          "question": "Brainstorming complete. concepts_brief.md is finalized. Select next step:",
          "options": [
            "Publish concepts_brief.md as RFC for team feedback",
            "Proceed to /egm-draft (Initialize formal design document)",
            "Continue refining concepts_brief.md in ideation mode",
            "Conclude brainstorming and keep brief for later"
          ],
          "is_multi_select": false
        }
      ]
    }
    
    • Option 0: Publish concepts_brief.md as RFC for team feedback:
      • Write concepts_brief.md to docs/designs/<feature_name>.md using your file-writing tool.
      • Register the RFC in docs/designs/SITEMAP.md if it exists.
      • Notify the user in chat that the RFC has been published and can be shared with the team for feedback before formal drafting. Remind the user that once feedback is gathered, a detailed design can be initiated by running /egm-draft docs/designs/<feature_name>.md.
    • Option 1: Proceed to /egm-draft (Initialize formal design document):
      • Confirm that concepts_brief.md is saved in the working directory or artifact directory.
      • Instruct the user to run /egm-draft (or activate the egm-draft skill), noting that /egm-draft automatically ingests concepts_brief.md as its Priority 1 intake source.
    • Option 2: Continue refining concepts_brief.md in ideation mode:
      • Return to Step 3 iteration loop to drill into further edge cases or update the brief based on user chat input.
    • Option 3: Conclude brainstorming and keep brief for later:
      • Conclude the session gracefully. Remind the user that concepts_brief.md remains saved for future reference.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

egm-bootstrap

Google 公式無料概要あり

リポジトリ内のソースコードを調べ、各ディレクトリの役割や公開インターフェース、制約をまとめたREADME.mdを階層的に作成・更新するスキルです。

  • リポジトリのREADMEを階層ごとに整備したいとき
  • 各パッケージの公開インターフェースを記録したいとき
  • 既存のREADMEをコードに合わせて更新したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-draft

Google 公式無料概要あり

要件や解決方針をまとめたブリーフやメモをもとに、概要から実装計画までを段階的に設計書へまとめ、各章を確認しながら仕上げるスキルです。

  • 合意した要件から設計書を作りたいとき
  • 機能メモを技術計画にまとめたいとき
  • 設計の代替案と不採用理由を残したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-drift-report

Google 公式無料概要あり

設計書やREADMEと現在のコードを照合し、仕様にない実装や未実装の機能、設計との差異を見つけて、文書ごとの報告書に整理します。

  • 設計書と実装の差異を調べたいとき
  • READMEの記述をコードと照合したいとき
  • 未実装の仕様を洗い出したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-resolve

Google 公式無料概要あり

複数のレビュー担当から集めた文書の指摘を根拠に沿って分類し、修正案の提示や修正適用、利用者との確認を進めるスキルです。

  • 複数のレビュー指摘を整理したいとき
  • 指摘への反論や修正案を文書化したいとき
  • 修正を項目ごとに判断したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-review

Google 公式無料概要あり

設計文書を全体像・理解しやすさ・設計上の課題・実装準備の観点から段階的にレビューし、指摘をレポートにまとめるスキルです。

  • 設計文書の抜けを実装前に確認したいとき
  • 仕様が読み手に伝わるか確かめたいとき
  • 実装準備の状態を評価したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-review-loop

Google 公式無料概要あり

複数の専門エージェントで設計書や仕様書を繰り返しレビューし、指摘の整理、修正案の確認、承認された修正の反映まで進めるスキルです。

  • 設計書を複数の観点からレビューしたいとき
  • 仕様書の抜けや前提を確認したいとき
  • 実装計画の準備状況を点検したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

google のスキルをすべて見る

このスキルの問題を報告する