name brainstorming
description Use before creative or constructive work — designing a feature, an architecture, a workflow, a document, a plan, or any non-trivial change — to turn a vague idea into a validated design before implementation begins. Surfaces intent, constraints, and alternatives through structured collaboration.
allowed-tools Read · Glob · Grep

Brainstorming Ideas Into Designs

Purpose

Turn raw ideas into clear, validated designs and specifications through structured dialogue, before any implementation begins.

This skill exists to prevent:

  • premature implementation
  • hidden assumptions
  • misaligned solutions
  • fragile systems

Hard rule: while this skill is active, stay in design. No implementing, writing code, scaffolding, or modifying behavior until a design has been presented and the user has approved it.

Operating Mode

You're acting as a design facilitator and senior reviewer, not a builder:

  • no unrequested features (YAGNI)
  • no silent assumptions
  • no skipping ahead

The job is to slow the process down just enough to get it right.

Anti-Pattern: "This Is Too Simple to Need a Design"

Resist the instinct to skip design on "simple" work — a quick utility, a config change, a one-page doc, a weekend trip. That's exactly where unexamined assumptions do the most damage, because no one slows down to check them. So default to designing even small things; the design can be short — a few sentences for genuinely tiny ones.

This is a strong default, not a mandate: the opening check lets the user wave a genuinely trivial item straight through.

Scope Check

Before diving into detailed questions, assess scope. If the idea is really several independent pieces (e.g. "a platform with chat, billing, and analytics" — or "get my finances in order," which is really budgeting, debt payoff, and retirement planning), say so up front and help decompose it into sub-projects first — what the independent pieces are, how they relate, and what order to build them. Each piece then gets its own design → plan cycle. Don't spend questions refining the details of something that needs to be broken apart first.

The Process

Opening gate — ask before diving in

This skill can fire on its own when creative or constructive work seems to be starting. When it does, don't silently launch into a full design pass — surface it and let the user choose. Briefly name what you think is being designed, then ask whether they want to brainstorm it or just proceed. Default toward brainstorming (the Anti-Pattern above is why), but a genuine "it's trivial, just do it" is a valid answer — step aside if you get one.

If the user invoked the skill explicitly, they've already opted in: treat this as a quick "here's what I think we're designing — right?" confirmation rather than asking whether to brainstorm at all.

1. Understand the Current Context (first step)

Before asking any questions:

  • Review the current project state, if available: files, documentation, plans, prior decisions
  • Identify what already exists vs. what's proposed
  • Note constraints that seem implicit but unconfirmed

Don't design yet.

2. Understanding the Idea (one question at a time)

The goal here is shared clarity, not speed.

  • Ask one question per message
  • Prefer multiple-choice questions when possible; open-ended when necessary (the AskUserQuestion tool is the natural vehicle — a button-press is lower-friction to answer than free text)
  • If a topic needs depth, split it into multiple questions

Focus on understanding:

  • Purpose — what problem this solves, and for whom
  • Constraints & success criteria — the real-world limits the result must respect and the bar it must clear. Translate to the domain: for software, things like performance, security, reliability; for a trip, a budget ceiling, dates, mobility; for a budget, risk tolerance and timeline. Ask what "done well" looks like — and what would count as failure.
  • Explicit non-goals — what this deliberately won't do

3. Understanding Lock — the gate before design

Before proposing any design, pause and lay out:

Understanding summary — a concise 5–7 bullets: what's being designed, why it exists, who it's for, key constraints, explicit non-goals.

Assumptions — list them explicitly.

Open questions — list any that remain.

Then ask: "Does this reflect your intent? Confirm or correct anything before we move to design."

Gate: do not proceed to design until the user confirms.

4. Explore Design Approaches

Once understanding is confirmed:

  • Propose 2–3 viable approaches
  • Lead with your recommended option, and explain why it's your recommendation
  • Explain the trade-offs along whatever axes matter for the domain — e.g. cost, effort, risk, flexibility, reversibility, maintenance. Translate to the work: for software that might be complexity vs. extensibility; for a trip, money vs. time vs. flexibility; for a budget, return vs. risk vs. liquidity.
  • Present these conversationally, with room for the reasoning — this is a discussion to think through, not a multiple-choice pick
  • Avoid premature optimization (YAGNI)

This is still not the final design.

5. Present the Design (incrementally)

  • Scale each section to its complexity: a few sentences when straightforward, up to ~250 words when nuanced
  • After each section, ask: "Does this look right so far?"
  • Cover, as relevant: the design's main parts, how they connect, how it handles failure and edge cases, and how you'll know it works. Translate to the domain: for software that's architecture, components, data flow, error handling, and testing; for a trip, the itinerary legs, how they connect, contingency for delays, and what counts as the trip going well.

6. Decision Log

Keep a running decision log through the discussion. For each decision, record what was decided, the alternatives considered, and why this option was chosen. Preserve it for the documentation step.

After the Design

Documentation

Once the design is validated, write it to a durable, shared format (e.g. Markdown), including the understanding summary, assumptions, decision log, and final design.

Save it to whichever context the design belongs to — not to Yggdrasil:

  • Designing something for an execution partner (e.g. Odin Codin')? Save it in that partner's repo working directory.
  • Designing something project-specific? Save it in the project layer.
  • Designing Yggdrasil itself? working/ in this repo is the right place.

Name it <short-name>-design.md — no date while it's active (a design built over several days has no single obvious date, and a dateless stem pairs cleanly with the plan). The -design suffix marks a brainstorming output and pairs with the planning skill's -plan suffix, so a design/plan pair shares the exact stem and sits together (e.g. list-hygiene-design.md ↔ list-hygiene-plan.md). A date is prepended only when the doc is archived (YYYY-MM-DD-<short-name>-design.md), where chronology earns its place.

Tell the user where you saved it — the planning skill will need to find it. Saving the file is enough for now; it's durable. Hold off on committing until the final review below — that's the natural commit point, and you can prompt the user for it then.

Self-Review

After writing the design, look at it with fresh eyes before handing off:

  • Placeholders: any "TBD", "TODO", or vague requirement? Resolve them.
  • Consistency: do any parts contradict each other?
  • Scope: focused enough for a single plan, or does it need decomposition (see Scope Check)?
  • Ambiguity: could any requirement be read two ways? Pick one and make it explicit.

Fix issues inline — no need to re-review, just fix and move on.

Final Review (with the user)

After your own self-review, walk the written design with the user one section at a time — read a section together, invite corrections, then move on to the next. This is a shared read of the finished artifact, distinct from the solo fresh-eyes pass above.

When the walk is done and the user is satisfied, this is the natural point to commit the design doc — prompt the user for it if they haven't already called it.

Implementation Handoff

Only after the design is documented, self-reviewed, and walked through with the user, ask: "Ready to turn this into a plan?"

If yes, recommend running /planning — Yggdrasil's writing-plans-style skill — to turn the validated design into an executable, checkpoint-able plan. Recommend it the way you'd recommend a save or a commit: surface that we've reached the seam and that planning is the next step, then let the user invoke /planning themselves rather than chaining into it automatically. Don't begin implementation directly from here — turning the design into a plan is the only next step.

Exit Criteria

Exit brainstorming only when all of these are true:

  • Understanding Lock confirmed
  • at least one design approach explicitly accepted
  • major assumptions documented
  • key risks acknowledged
  • decision log complete
  • design documented and walked through with the user

Gate: if any criterion is unmet, keep refining — do not proceed to implementation.

Key Principles

  • One question at a time
  • Assumptions must be explicit
  • Always explore alternatives
  • Validate incrementally
  • Prefer clarity over cleverness
  • Be willing to go back and clarify
  • YAGNI