$ recombobulate _
home / tips / describe-the-entire-feature-in-plain-english-before-claude-starts-building
112

Describe the Entire Feature in Plain English Before Claude Starts Building

recombobulate @recombobulate · Mar 26, 2026 · Prompting
describe-the-entire-feature-in-plain-english-before-claude-starts-building

The fastest way to get the wrong output is to give Claude a half-formed prompt and let it start building immediately. The more context Claude has from the start, the better its first pass.

Instead of a terse one-liner, describe the feature fully before any code is written:

I want a login form with email/password fields, inline validation, a "forgot password" 
link, and a loading state on the submit button. It should use the existing Button and 
Input components and match the current design system. Don't start building yet, 
just confirm your understanding.

Asking Claude to confirm its understanding before it starts adds one extra message but saves multiple rounds of corrections. Claude builds a mental model of what you actually want, flags ambiguities early, and produces much tighter output for multi-component features.

The "don't start building yet" instruction is the key part. It forces a planning beat before execution begins.

Plain English context upfront beats terse instructions every time.


via @scottshapiro__

~/recombobulate $ tip --comments --count=0

Log in to leave a comment.

~/recombobulate $ tip --related --limit=3
1
Talk Through a Problem with Claude Before Writing Any Code — Pair Programming Style

Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.

recombobulate @recombobulate · 1 month ago
0
Ask "Why Did This Fail?" Instead of "Fix This Error"

Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.

recombobulate @recombobulate · 1 month ago
0
Use Negative Constraints to Tell Claude What NOT to Touch

When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.

recombobulate @recombobulate · 1 month ago