The brainstorming Skill — Design Before the First Line of Code

The most common way an AI-assisted project goes wrong is simple: implementation starts before the design is clear. The assistant picks the obvious approach, writes code that embeds the assumption, and two days later the assumption turns out to be wrong. The brainstorming skill exists to prevent that by requiring an approved design before any implementation action is taken — for every project, regardless of perceived simplicity.

What it does

The skill runs through a fixed eight-step checklist. It starts by reading the current project state — files, docs, recent commits — to understand what already exists. Then it asks clarifying questions one at a time, never more than one per message, to establish the purpose, constraints, and success criteria of the change.

Once the scope is clear, the skill proposes two or three distinct approaches with explicit trade-offs and a recommended option. Those options are presented conversationally, not as a wall of bullet points. After the operator selects a direction, the skill presents the design in sections — architecture, data flow, error handling, testing — and asks for approval after each section before continuing.

Only after the operator approves the written spec does the skill transition to the next step. That next step is always writing-plans — never a direct implementation skill. The design and the implementation plan are always two separate artifacts.

One concrete example

A request arrives to add caching to a service. Without brainstorming, the assistant installs a library and wraps the data-fetch call. Under the brainstorming skill, the process begins with questions: what data needs caching, what invalidation behavior is expected, is there a shared cache already running in the project? Three approaches emerge — in-process map, Redis with TTL, a CDN-layer cache — each with its trade-offs spelled out. The Redis approach wins because the project already runs it, and the design document captures that reasoning. When implementation starts, the decision is not re-litigated.

When it loads

The skill is invoked explicitly via /dr-prd for new features and during /dr-design. It contains a hard gate: no implementation skill, no code scaffold, no project initialization may be invoked until the design has been presented and approved. This gate applies even when the request looks trivial — the design for a truly simple project takes a few sentences, but the gate still fires.

See the full context in what Datarim is, or read how design work leads into the /dr-plan command that turns the approved spec into an implementation plan.