From android-dev
Research and design a solution before implementation. Analyzes context, asks questions, proposes 2-3 approaches with trade-offs, writes a specification. For non-trivial tasks that require thinking before coding. <example> Context: User wants to discuss an implementation approach user: "what's the best way to implement payment system integration?" assistant: "Using brainstorm skill to research approaches." </example> <example> Context: User wants to think through architecture user: "let's think about how to implement caching" assistant: "Running brainstorm to analyze caching options." </example> <example> Context: Complex feature with a non-obvious solution user: "need to add offline mode, where to start?" assistant: "Starting with brainstorm — will research current architecture and propose options." </example>
How this skill is triggered — by the user, by Claude, or both
Slash command
/android-dev:brainstormThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You help think through a solution BEFORE writing code. Your goal is to research the problem, propose approaches, and create a specification.
You help think through a solution BEFORE writing code. Your goal is to research the problem, propose approaches, and create a specification.
DO NOT IMPLEMENT ANYTHING DURING BRAINSTORM. The outcome is a specification, not code.
Topic for discussion: $ARGUMENTS
Before proposing anything — understand the current state:
google-dev-knowledge:google-dev-docs to study APIsFormulate the problem clearly:
Ask the user 2-3 targeted questions using the AskUserQuestion tool (one at a time). This is mandatory — DO NOT write questions as plain text, ALWAYS use AskUserQuestion with answer options where possible.
Topics to clarify:
Present 2-3 approaches, each:
### Approach {N}: {name}
**Summary**: {1-2 sentences}
**How it works**:
- {key detail 1}
- {key detail 2}
- {key detail 3}
**Pros**:
- {advantage 1}
- {advantage 2}
**Cons**:
- {disadvantage 1}
- {disadvantage 2}
**Complexity**: Low / Medium / High
**When to choose**: {scenario when this approach is best}
Finish with a clear recommendation and rationale.
Approaches must be fundamentally different, not variations of the same idea.
After the user selects an approach — create a document:
.claude/docs/android-dev/designs/{feature-name}.md# Design: {feature-name}
Date: {YYYY-MM-DD}
## Problem Statement
{What we're solving and why}
## Chosen Approach
{Description of the selected approach}
## Architecture
{How components interact, data flow, key abstractions}
## Key Decisions
- {Decision 1}: {rationale}
- {Decision 2}: {rationale}
## Affected Files
- Create: {list of new files}
- Modify: {list of files to change}
## Delivery Slices (vertical slices)
- Slice 1: {full path through all layers UI -> logic -> data}
- Slice 2: {next slice}
## Open Questions
{Unresolved items — marked with a warning}
After the specification is approved:
plan skill?"npx claudepluginhub gorban-dev/gor-dev-plugins --plugin android-devGuides collaborative brainstorming to refine fuzzy requirements, explore implementation alternatives, and form designs before coding.
Transforms vague ideas into clear, validated designs via structured dialogue before implementing features, architecture changes, or behavior modifications.
Refines rough ideas into fully-formed designs via phased process: Socratic questioning for understanding, alternative exploration with trade-offs, and incremental validation before coding.