Guide collaborative brainstorming sessions to clarify requirements before planning. Covers batched multiple-choice questions, adaptive exit, and design document capture. Triggers on: brainstorm, explore idea, think through, what should we build.
From aimi-engineeringnpx claudepluginhub aimi-so/aimi-engineering-plugin --plugin aimi-engineeringThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Deprecated: This skill is no longer loaded by brainstorm.md. The command is self-contained. Retained for reference only.
Clarify WHAT to build through collaborative dialogue before planning HOW to build it.
Guide the user through structured brainstorming: understand the idea via research and batched questions, optionally explore approaches, then capture decisions in a design document.
The brainstorm uses a two-phase question approach:
/aimi:brainstorm [description] inputThis combines the speed of Ralph-style shorthand ("1A, 2C, 3B") with context-aware questions that reference actual codebase patterns.
Present questions as batched multiple-choice using Ralph-style formatting:
1. What is the primary goal?
A. Improve user experience
B. Reduce technical debt
C. Add new capability
D. Other: [please specify]
2. What is the scope?
A. Minimal viable version
B. Full-featured implementation
C. Just the backend/API
D. Other: [please specify]
3. Who is the target user?
A. End users
B. Developers/API consumers
C. Admin users
D. All users
Rules:
Accept all response formats gracefully:
| Format | Example | Action |
|---|---|---|
| Shorthand | "1A, 2C, 3B" | Parse directly |
| No numbers | "A, C, B" | Map to questions in order |
| Free-form | "I prefer option A for the first one" | Parse intent |
| Partial | "1A, 2C" (skipped 3) | Accept partial, ask about skipped if critical |
| Mixed | "1A but for question 3 none fit — I want X" | Parse shorthand + free-form |
Never re-ask a question just because the format was unexpected. Parse the intent and continue.
When codebase research returns findings, generate contextual options:
When research is empty or fails, fall back to generic topic-based questions.
Cover these categories across question rounds:
| Topic | Focus |
|---|---|
| Purpose | What problem does this solve? What's the motivation? |
| Users | Who uses this? What's their context? |
| Constraints | Technical limitations? Timeline? Dependencies? |
| Success | How will you measure success? What's the happy path? |
| Edge Cases | What shouldn't happen? Error states? |
| Existing Patterns | Similar features in the codebase to follow? |
Exit questioning when ANY of these are met:
After each round, assess which topics remain uncovered and generate targeted follow-up questions.
Only propose approaches when multiple valid paths exist. Skip when there's one obvious direction.
If proposing approaches, present 2-3 with this structure:
### Approach A: [Name]
[2-3 sentence description]
**Pros:** [bullet list]
**Cons:** [bullet list]
**Best when:** [one sentence]
Lead with a recommendation and explain why. Apply YAGNI — prefer simpler solutions.
Apply these throughout brainstorming:
Write brainstorm output to .aimi/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md:
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
# <Topic Title>
## What We're Building
[Concise description — 1-2 paragraphs max]
## Why This Approach
[Approaches considered and rationale for choice]
## Key Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]
## Open Questions
- [Any unresolved questions]
## Next Steps
> Run `/aimi:plan` to generate implementation tasks
Before handoff, resolve all open questions. If the design document has items in the Open Questions section, ask the user about each one. Move resolved questions to a "Resolved Questions" section. Only proceed to handoff when Open Questions is empty or the user explicitly defers them.
Derive the filename slug from the feature description:
Example: "Add social login with Google and GitHub OAuth" → add-social-login-with-google-and-github-oauth
When interpolating the user's feature description into research agent prompts, strip:
Keep output sections concise (200-300 words max). After presenting approaches or key decisions, pause to validate:
Before saving the brainstorm document:
/aimi:plan.aimi/brainstorms/ exists