brainstorming

To turn ambiguous product ideas into an approved design spec, you need a structured discovery process that explores context, asks clarifying questions, proposes trade-offs, and validates requirements iteratively before implementation.

The best way to define feature scope and refine requirements is through a staged workflow that includes context exploration, single-question clarification, multi-approach trade-off presentation, spec writing, and an approval gate that defers implementation until design sign-off is obtained.

You present design trade-offs by proposing 2–3 approaches with clear pros and cons, recommending a path, and pausing the staged design process for explicit user sign-off before writing the final design spec to the standard specs folder.

No, this brainstorming workflow includes a hard gate against coding. It transitions safely to implementation planning only after the design spec is explicitly approved, handing off to the writing-plans skill rather than starting development directly.

Yes, you can use this structured discovery process for both engineering and product design changes. It applies to feature design, scope definition, and requirement refinement across software changes where implementation must be deferred until design approval is obtained.

You ground design decisions in the current codebase by starting the brainstorming workflow with context exploration, which reviews existing files, docs, and commit state to ensure all proposed approaches and trade-offs align with the existing project architecture.