Most people use Claude like a vending machine: type a question, take an answer, close the tab, lose everything. Then they wonder why it feels mid.
The people getting absurd leverage out of it aren't better at prompting. They've just stopped starting from scratch. Here are the 12 habits I killed, and what I do now.
Context
Never explain yourself twice
Most people's Claude is worse than it should be for one reason: it starts every conversation as a stranger. These four fix that permanently.
I never start a new chat with zero context.
I keep dedicated Projects for the different parts of my life — clients, content, business, coding, ideas. Each one already has instructions, files, and context loaded, so Claude knows what it's helping with before I type a word.
Create one Project per area of your life. Drop a context.md in each: what this is, who it's for, what good looks like, what to never do. Twenty minutes once — every conversation after that starts warm.
I never explain myself over and over.
I have documents for my writing style, brand voice, preferred formatting, common prompts, and how I make decisions. Claude reads those instead of making me repeat myself.
Write one style guide: 8–10 samples of your actual voice, your formatting rules, and the words you never use. Put it in the Project. Claude matches you instead of you correcting it every time.
I never use one giant project for everything.
Separate Projects keep context clean. My content doesn't bleed into client work, and startup planning doesn't pollute a coding conversation.
Split by context, not by topic. If two things need different background knowledge to answer well, they're different Projects. Mixed context produces mushy answers.
I never let important knowledge disappear into old chats.
If I figure something out once, it becomes documentation. SOPs, frameworks, checklists, prompts, and workflows all live in the Project so future conversations build on them instead of starting over.
End any session where you solved something with: “Turn what we just worked out into an SOP I can reuse.” Save it to the Project. That's the whole habit.
Systems
Build the thing that builds the thing
The gap between people who get a lot out of AI and people who don't isn't prompting skill. It's whether the work compounds or evaporates.
I never start building before designing the system.
Before any code gets written, I have Claude produce the architecture, folder structure, database schema, API plan, edge cases, milestones, and deployment checklist. It prevents expensive rewrites later.
Ask in that exact order, one at a time — architecture first, deployment last. Each answer becomes context for the next. An hour here saves a week of rewrites.
I never reinvent prompts.
The prompts I use every week are saved as reusable templates. I change a couple of variables instead of rewriting the instructions from scratch.
Rule of thumb: any prompt you've written twice becomes a template with {variables}. Keep a prompts.md in each Project.
I never leave projects undocumented.
Every project gets a README, a decision log, a roadmap, naming conventions, and onboarding notes. If I disappear for a month, I can pick it straight back up.
The decision log is the one people skip and regret. One line per call: what you decided, and why. Future-you will not remember why, and neither will Claude.
I never rely on memory for repetitive work.
Proposals, outreach, documentation, onboarding, content outlines, planning — they all have a reusable system behind them. Claude fills in the details instead of me rebuilding the whole thing.
List everything you've done more than three times. Each one gets a template this week. That list is your system.
Thinking
Collaborator, not search engine
This is where most of the value actually is, and where almost nobody spends their time.
I never ask vague questions.
Instead of “how do I build this?”, I give constraints, success criteria, target users, examples, and trade-offs. Better context produces dramatically better answers.
Upgrade every question with four things: who it's for, what it must do, what it can't do, and what to optimize for. “How do I build this” becomes “Build X for Y. Must do Z. Can't do W. Optimize for speed over elegance.”
I never trust the first answer blindly.
I ask Claude to critique its own response, name its assumptions, point out the weak spots, and offer alternatives before I act on anything.
One line, every time it matters: “Critique that. What did you assume? Where is it weakest? What's a better approach?” The second answer is routinely far better than the first.
I never treat Claude like a search engine.
I treat it like a collaborator — asking it to challenge my ideas, pressure-test decisions, compare options, and think through second-order effects.
Stop asking what. Start asking “what breaks if I'm wrong?”, “what's the strongest case against this?”, and “what happens six months after this works?”
I never learn AI randomly anymore.
I learn exactly what's needed for the thing I'm building today. Every lesson has an immediate application, so it actually sticks.
Kill the tutorial backlog. Pick what you're building this week, learn only what that needs. Applied once beats watched five times.
If you only do one thing today
Make one Project for the thing you work on most. Give it a context.md — what it is, who it's for, what good looks like, what to never do. That single file changes every conversation you have inside it from here on.
You don't need all twelve. You need the first one.
The advantage isn't using AI anymore.
Everyone uses AI.
The advantage is building a system that compounds every time you use it.
Want the next one first?
The Input Daily — a 5-minute AI brief every weekday. 3 stories that matter, 1 tool worth trying, 1 prompt to steal.
Free. Every morning. Unsubscribe in one click. Privacy Policy.