brainstorming

Start by exploring the current project context, then answer clarifying questions one at a time about purpose, constraints, and success criteria. The process proposes 2-3 approaches with trade-offs, presents the design in sections for approval, and writes the final spec to a dated markdown file.

The workflow follows a fixed checklist: explore project context, ask clarifying questions, propose approaches, present the design for approval, write the spec document, self-review it, get user review, then transition to implementation planning. No code is written until the design is approved.

Yes, the visual companion serves HTML mockups, wireframes, and diagrams through a local server that users open in a browser. It is offered once for consent and used per-question only when content is genuinely visual rather than conceptual.

Decompose when the request describes multiple independent subsystems, such as a platform with chat, billing, and analytics. Each sub-project gets its own spec, plan, and implementation cycle rather than one oversized design.

The process adds upfront dialogue time, which can feel heavy for trivial changes, though the skill mandates it even for simple projects with shortened designs. It also blocks all implementation until the user explicitly approves the written spec.