Brainstorm

Brainstorm is where an idea becomes a backlog. Talk it through by voice or type it out. Masaro asks the sharp questions and returns scoped epics and tasks with acceptance criteria, not a tidier version of your ramble.

How a session works

Start a brainstorm and describe what you want to build, at whatever altitude you have: “a CLI that syncs my notes” or three paragraphs of half-formed product thinking. Both are fine; the point of the session is to close the gap.

Masaro pushes back the way a good tech lead does:

  • “What happens when the sync conflicts: last write wins, or merge?”
  • “Is auth in scope for v1, or single-user?”
  • “You said ‘fast’: fast like sub-second, or fast like not-embarrassing?”

These aren’t filler prompts. Each answer becomes structure: a scope boundary, a dependency, a criterion. Vague in, specific out.

Voice, if you think out loud

Some ideas survive typing; most die in the second sentence. Voice mode lets you ramble: pace around, contradict yourself, circle the point. Masaro listens for the decisions inside the noise and asks about the gaps. Typing works exactly the same way if that’s your speed.

What comes out

A draft plan: epics for the major chunks, tasks scoped to real engineering work, dependencies where sequencing matters, complexity estimates, and acceptance criteria on the tasks that need them. It reads like a backlog written by someone who was paying attention, because something was. And it’s a backlog the whole team can execute: the structure is the same whether the next task goes to a teammate or an agent.

You review before anything lands

The draft is a proposal. Edit tasks, tighten criteria, delete the epic you don’t believe in, accept the rest. Nothing enters your backlog without your sign-off. Masaro is fast at drafting; you stay the editor.

Best input for a brainstorm isn’t a spec; it’s honesty about what you don’t know yet. The questions do their best work on the fuzzy parts.

Next