Brainstorm before you build — using LingCode to clarify scope first

The natural instinct with an AI coding tool is to type your idea and hit return. "Add a leaderboard." "Build me a settings page." "Make a chat panel." LingCode will produce code for those. It will also produce code that misses what you actually wanted, because you never said.

Three things go wrong when you skip the brainstorm:

• Hidden requirements stay hidden. A "settings page" needs to know which settings, whether they're per-user or per-workspace, how they persist, how they sync. None of that is in the prompt. LingCode will pick reasonable-sounding defaults — and you'll find out at integration time that "reasonable-sounding" wasn't right.
• Scope creeps invisibly. Without an agreed boundary, the implementation grows. The "leaderboard" gains a friends filter, then weekly resets, then push notifications — none of which you asked for. Removing them later is harder than not adding them.
• You can't say "no" to a design you never saw. Architectural choices get baked into the first file LingCode writes. By the time you're reviewing the code, redoing them is rewriting, not deciding.

A short brainstorm — three exchanges, maybe five minutes — pulls all of that into the open before code exists. It's the cheapest correction window you'll ever have.

This isn't free-form chatting. The brainstorm has a shape:

1. Intent — what problem are you trying to solve, and for whom? Not "what feature." What outcome.
2. Requirements — what must be true when this is done? Functional, non-functional, and explicitly out-of-scope items.
3. Design sketch — one paragraph (not a doc) of how it'll work. Just enough that you can both point at it.

You drive the first item. LingCode drives the next two by asking questions back at you. The conversation ends when you can both restate the design in one sentence.

Tell LingCode the problem before you tell it the solution. A prompt that works:

I want to brainstorm before we write any code. Don't propose
implementation yet.

The problem: users on the free tier keep hitting our quota and
churning silently — no email, no upgrade prompt, just gone. I want
to catch them before that happens.

Ask me clarifying questions until you understand the scope. Then
list the requirements you've extracted. Then sketch one design in
a paragraph. Stop after the sketch.

Notice what's missing: any mention of "send an email," "show a banner," "build a dashboard." Those are solutions. The brainstorm should question whether they're the right ones.

LingCode will come back with questions. Good ones look like:

• "How do you currently detect that a user is about to churn — last-active time, request volume hitting quota, both?"
• "Is the goal to warn them, upgrade them, or just measure the churn rate first?"
• "Where does notification belong — in-product banner, email, both? What channels do you already operate?"
• "What's out of scope for v1? Cohort analysis? Win-back campaigns? Sales hand-off?"

Answer them. The trap here is hand-waving. "I dunno, whatever makes sense" pushes the choice back to LingCode, which is the same as no brainstorm. If you genuinely don't know, say "I don't know — what are the trade-offs?" and let LingCode lay out the options. Then pick.

Once the clarifying round settles, ask LingCode to write the requirements down:

Good. Now list what we've agreed on as a bulleted requirements
list. Three sections:
- Must do (the actual feature)
- Must not do (out of scope for v1)
- Must respect (constraints — perf budget, dependencies, existing
  patterns to match)

Be specific. "Sends an email" is bad. "Sends one email per user
per 24-hour window when they exceed 80% of monthly quota" is good.

Read the list. If anything is wrong, say "no, actually..." and let LingCode revise. The "must not do" section is the one founders skip and engineers love — it's the boundary that prevents scope creep when implementation starts.

Now request a single design sketch:

Sketch one design — not three options. Just commit to an approach
and justify it in a paragraph. Cover:
- Where the detection logic lives (cron? request middleware?
  background job?).
- What state we track and where it persists.
- How the notification ships (which channel, what triggers it).
- What we change in the existing codebase vs. add new.

One paragraph. No code. If something's genuinely a coin-flip,
name the trade-off and pick anyway.

"Pick anyway" is the key constraint. Multiple-options sketches feel safe but punt the decision back to you — the brainstorm is supposed to make the decision, not defer it. If the trade-off matters, you'll catch it in the justification and push back. If it doesn't, LingCode's pick is fine.

The brainstorm is done when both of you can restate the design in one sentence. Ask:

In one sentence — what are we building?

If LingCode's sentence matches what's in your head, you're done. If it doesn't, you have one more clarifying loop to do. The mismatch is the bug, and you caught it before writing any code.

Save the requirements list and the design sketch somewhere — a scratch file, a doc, the chat history. The next step (writing an implementation plan) starts from this.

A done brainstorm has three artifacts:

• A one-paragraph intent statement — the problem and who has it.
• A requirements list — must do / must not do / must respect.
• A one-paragraph design sketch — committed, justified, no alternatives.

That's it. Not a design doc. Not a spec. Just enough to write an implementation plan against. If you've got more than that, you over-brainstormed; if you've got less, you under-brainstormed.

The natural next step is to turn this into a plan that orders the work and exposes the riskiest step — see the "Write an implementation plan" tutorial below.

Package the brainstorm pass as a skill so LingCode invokes it automatically before any creative work — asking for a feature, scaffolding a project, designing a component:

---
name: brainstorm
description: Use BEFORE any creative work — building a feature, scaffolding a project, designing a component, adding functionality. Forces scope clarification, requirement gathering, and a tiny design sketch before code is written. Triggers: 'let's build', 'I want to add', 'help me design', 'how should I approach', 'what should we build', 'design X'. Actions: brainstorm, clarify, scope, requirement-gather, sketch, design-doc, plan. Stops vague prompts from producing vague code.
---

Run a short brainstorm pass before proposing implementation.

1. Intent: ask what problem we're solving and for whom. Don't
   accept a feature description — push for the outcome.

2. Clarify: ask the questions that the prompt didn't answer.
   Trade-offs, scope edges, existing patterns to match,
   constraints. Keep going until the picture is concrete.

3. Requirements: write a bulleted list with three sections —
   Must do, Must not do, Must respect. Be specific.

4. Design: sketch ONE design in a paragraph. Commit to an
   approach. No alternatives. Justify briefly. No code.

5. Restate: summarize in one sentence. Stop and wait for user
   confirmation before writing any code.

If the brainstorm exceeds ~10 minutes of exchanges, the feature
is too big — break it into smaller pieces and brainstorm each.

Save as ~/.lingcode/skills/brainstorm/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →