Brainstorm
Run /brainstorm to separate goals from implementation and capture testable acceptance examples before AgentOps discovery and BDD intent work.
Overview
brainstorm is a journey-wide agent skill that clarifies goals before planning—usable whenever a solo builder needs to separate WHAT from HOW before committing to AgentOps BDD and discovery.
Install
npx skills add https://github.com/boshu2/agentops --skill brainstormWhat is this skill?
- Two modes: goal-clarification (default) and ideation before HOW exploration
- Upstream of AgentOps step 1—shape intent as BDD for /discovery
- Capture requires at least one happy path and one critical edge in testable Gherkin
- Consumes standards; produces result.json and verdict.json under a findings contract
- Explicit loop position in operating-loop.md—not ad-hoc chat brainstorming
- Two complementary modes: goal-clarification and ideation
- Capture gate: at least one happy path and one critical edge in testable Gherkin
- Four-phase goal-clarification flow documented in SKILL.md
Adoption & trust: 807 installs on skills.sh; 384 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a vague goal or competing ideas and risk baking implementation into requirements before anyone can test whether the capability is right.
Who is it for?
Builders using AgentOps who want Gherkin-ready acceptance examples and verdict-shaped JSON before discovery or implementation.
Skip if: Skipping when you already have an approved spec with happy-path and critical-edge Gherkin—or when you only need unrelated refactors with no new capability.
When should I use this skill?
Invoke /brainstorm when you have a free-text goal or competing ideas and have not yet completed testable Gherkin capture for /discovery.
What do I get? / Deliverables
You capture Given/When/Then-shaped happy and edge paths in structured outputs, then hand off to /discovery for BDD intent issues when capture is complete.
- result.json and verdict.json per output contract
- Findings aligned to skills/research/schemas/findings.json
- Given/When/Then acceptance examples ready for intent issues
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Run ideation mode to compare three agent features, then goal-clarify the winner before any repo changes.
Turn a one-line product goal into happy-path and edge Gherkin before opening a BDD intent issue.
Re-brainstorm when a sprint task expanded scope without updated acceptance examples.
Check whether shipped behavior still matches captured examples before you tag a release.
Clarify a production incident fix as WHAT outcomes before picking HOW to patch.
How it compares
Structured AgentOps prelude with JSON contracts, not a generic whiteboard brainstorm with no acceptance capture gate.
Common Questions / FAQ
Who is brainstorm for?
Solo and indie builders on boshu2/agentops who want domain-level goal clarity and BDD-shaped examples before planning and discovery.
When should I use brainstorm?
Use it journey-wide before planning: at Validate/scope for new capabilities, at Idea/discover when goals are fuzzy, at Build/pm before slicing work, and at Ship/review when intent drifted from original acceptance examples.
Is brainstorm safe to install?
Review the Security Audits panel on this Prism page; the skill writes result and verdict JSON and consumes shared standards—inspect repo permissions and output paths in your workspace.
SKILL.md
READMESKILL.md - Brainstorm
# /brainstorm — Clarify Goals Before Planning > **Purpose:** Separate WHAT from HOW. Explore the problem space before committing to a solution. ## Loop position Upstream of move **1 (shape intent as BDD)** of the [operating loop](../../docs/architecture/operating-loop.md). Consumes a free-text goal; produces Given/When/Then-shaped acceptance examples that `/discovery` can fold into a [BDD intent issue](../../docs/templates/intent-issue.md). The Capture step (phase 4 below) is not complete until at least one happy path and one critical edge are written as testable Gherkin — "it should work" is not a captured example. ## Two modes `/brainstorm` runs in one of two modes. They are complementary, not exclusive — a session may start in ideation mode, pick one idea, and hand it to goal-clarification for HOW-exploration. | Mode | Use when | Shape | |------|----------|-------| | **Goal-clarification** (default; the four phases below) | The goal names ONE specific capability (`"add JWT auth"`, `"fix the login bug"`) | Sharpen the WHAT, explore the HOW for that single goal. | | **Ideation** (open-ended; see [Ideation Mode](#ideation-mode-open-ended-generate-winnow)) | The goal is open-ended (`"improve the project"`, `"what should we build next"`) OR Phase 1 returns `exploring` with no single goal emerging OR `--ideate` is passed | Generate MANY candidate improvements, winnow ruthlessly, operationalize the survivors. | The full mode-selection table lives in [references/ideation-mode.md](references/ideation-mode.md). Four phases (goal-clarification mode): 1. **Assess clarity** — Is the goal specific enough? 2. **Understand idea** — What problem, who benefits, what exists? 3. **Explore approaches** — Generate options, compare tradeoffs, adversarial critique 4. **Capture design** — Write structured output for `/plan` --- ## Quick Start ```bash /brainstorm "add user authentication" # full 4-phase process /brainstorm # prompts for goal ``` --- ## Execution Steps ### Phase 1: Assess Clarity If the user provided a goal string, evaluate it. Otherwise prompt for one. Use `AskUserQuestion` with options to gauge clarity: - **clear** — Goal is specific and actionable (e.g., "add JWT auth to the API") - **vague** — Goal exists but needs narrowing (e.g., "improve security") - **exploring** — No firm goal yet, just a direction (e.g., "something with auth") If **vague** or **exploring**, ask follow-up questions to sharpen the goal before proceeding. Do NOT move to Phase 2 until you have a concrete problem statement (one sentence, testable). ### Phase 2: Understand the Idea Answer these questions (use codebase exploration as needed): 1. **What problem does this solve?** — State the pain point in concrete terms. 2. **Who benefits?** — End users, developers, operators, CI pipeline? 3. **What exists today?** — Current state, prior art in the codebase, adjacent systems. 4. **What constraints matter?** — Performance, compatibility, security, timeline. Summarize findings before moving on. If anything is unclear, ask the user. ### Phase 3: Explore Approaches Generate **2-3 distinct approaches**. For each: - **Name** — Short label (e.g., "JWT middleware", "OAuth proxy", "Session cookies") - **How it works** — 2-3 sentences - **Pros** — What it gets right - **Cons** — What it gets wrong or defers - **Effort** — Rough scope (small / medium / large) #### Phase 3b: Adversarial Critique Before asking t