brainstorming

Brainstorming

Turn rough ideas into validated designs through structured dialogue before touching code or config.

Do NOT start implementation until a design is presented and the user approves it. This applies regardless of perceived simplicity — "simple" tasks are where unexamined assumptions cause the most wasted work.

Process

1. Explore context

Check the project state first: files, config, recent changes, existing patterns. Understand what exists before asking questions.

2. Ask clarifying questions

• One question at a time. Don't overwhelm with a list.
• Prefer multiple choice when there are known options. Open-ended when the space is genuinely open.
• Focus on: purpose, constraints, success criteria, what the user cares about most.

3. Propose approaches

Present 2-3 approaches with tradeoffs. Lead with your recommendation and explain why. Be honest about downsides.

If only one approach makes sense, say so and explain why alternatives don't work — don't invent fake options.

4. Present design

Once you understand what to build, present the design in sections scaled to complexity:

• A few sentences for straightforward sections
• More detail for sections with genuine tradeoffs
• Get approval after each section so the user can course-correct early

Cover: what changes, what stays the same, what the user needs to verify, and any decisions deferred to implementation.

5. Transition to implementation

Once the user approves the design, proceed to implementation. For migrations, this means entering the relevant migration phase. For other work, start executing.

When to use

• Migrations — before starting, explore the site structure and discuss editability tradeoffs (page builder vs static pages, what to make editable, content restructuring decisions)
• Adding features — before adding snippets, visual editing, or configuration to an existing site
• Restructuring — before reorganizing content, collections, or config
• Ambiguous requests — when the user says "make this work with CC" without specifying scope

When not to use

• Single, well-defined tasks with an obvious implementation ("add snippet: true to _editables")
• Bug fixes where the problem and solution are clear
• The user explicitly says "just do it" or provides a detailed spec

Contents

This skill is a single file — there are no deep-dives. Once a design is approved, implementation continues in the skill that owns the work:

Then go to	For
migrate-to-cloudcannon	A full migration, entering at Phase 1
cloudcannon-configuration	Collections, Inputs, Structures, Collection URLs
cloudcannon-visual-editing	Editable regions
cloudcannon-snippets	MDX components or inline HTML in content
make-site-multilingual	Rosey and the CloudCannon connector

Key principles

• One question at a time — don't overwhelm
• Multiple choice preferred — easier to answer than open-ended when options are known
• YAGNI — remove unnecessary complexity from designs
• Explore alternatives — always consider whether a different approach would be simpler
• Be honest — if something seems overcomplicated, say so. Push back on scope creep.
• Incremental validation — present design in sections, get approval before moving on

Common mistakes

Excuse	Reality
"This is too simple to need a design"	Simple tasks are where assumptions cause the most waste. The design can be short.
"I already know what to do"	You know what YOU would do. The user may have different priorities or constraints.
"Asking questions slows things down"	Wrong assumptions slow things down more. One question now saves rework later.
"The user will tell me if something's wrong"	Users often don't know what to flag until they see the wrong result. Validate upfront.
"I'll figure it out as I go"	That's how you end up redoing work. Explore the space first.