devflow-brainstorm

To clarify ambiguous feature requests before design, you can use a structured brainstorming process that prompts comprehensive clarifying questions to surface goals, constraints, edge cases, and the Definition of Done. This approach ensures the team establishes a clear problem understanding before any code or architecture work begins.

Surfacing assumptions during requirements refinement is best achieved by enforcing mandatory clarifying questions using a structured template. This prompts the team to define explicit goals, identify hidden constraints, and address edge cases before synthesizing a structured Problem Statement.

To write a problem statement for session memory, synthesize the clarified goals, constraints, and edge cases into a structured context.md file. This captures the agreed problem understanding and saves it to session memory, ensuring persistent context is available for downstream development phases.

Yes, you can use brainstorming sessions to define edge cases and constraints for new features. By applying structured clarifying questions, the session guides the team to explicitly outline limitations, boundaries, and expected behaviors before transitioning to the architectural design phase.

You should not use a requirements brainstorming approach for project handoff if your feature request is already fully defined with clear goals, constraints, and a problem statement. This process specifically targets ambiguous requests that require structured clarification before an architect phase begins.

No, devflow-brainstorm does not generate architecture proposals during requirements refinement. It enforces strict guardrails that prevent code writing or architecture proposals until the handoff to the Architect phase, focusing solely on problem understanding and clarifying questions.