# You’re Using Claude Wrong (And It’s Not Your Fault) > Source: > Published: 2026-06-15 07:12:21+00:00 Here’s a confession: for months, I used Claude exactly like I used every other chatbot before it. Open a new chat. Type a question. Get an answer. Close the tab. Repeat tomorrow — and re-explain my entire project from scratch, again. Sound familiar? Maybe you’ve felt it too. You paste the same “context” paragraph into every new conversation. You ask for a “quick script” and get something that *almost* fits your codebase, but not quite. You think, “Claude is good, but is it really that different from the others?” Here’s the uncomfortable truth: **if this is your experience, you’re running Claude at about 25% of its actual capacity.** You’re not using a flawed tool — you’re using a powerful tool the wrong way. Claude isn’t really a chatbot. It’s a productivity *system* — one that includes persistent memory, reusable expert workflows, and live, iterable outputs. Most people never discover this side of it because nobody hands you the manual. They just open the chat window and start typing. This article is that manual. We’re going to walk through exactly how the “wrong way” fails, what the “right way” looks like in practice, and how three core features — **Projects, Skills, and Artifacts** — work together to turn Claude from a text generator into something closer to a senior technical partner who never forgets your context. When I first started researching Claude’s advanced features, I realized I had been repeating the same context across conversations for months without noticing how much time it was costing me. Let’s start with what’s actually going wrong. When you treat Claude like a basic chatbot, you’re implicitly asking it to read your mind. A prompt like *“Write a Python script for a dashboard”* contains almost no real information. What kind of dashboard? What data? What libraries? What’s your team’s style guide? Claude has to guess — and guessing is where inconsistency creeps in. Multiply that by every new conversation, where you’re re-pasting the same brand voice guidelines, the same coding standards, the same “here’s what my company does” backstory — and you start to see the real cost. It’s not that Claude forgets things *within* a session. It’s that every new session starts from zero, and you’re the one paying the re-explanation tax, every single time. The fix isn’t a better prompt. It’s a better *system* for giving Claude context — one that persists, so you stop paying that tax altogether. That system starts with Projects. A Project is a persistent workspace — a place where you group documents (your “Knowledge Base”) and standing instructions that Claude reads automatically at the start of every session in that workspace. Think of it less like “starting a chat” and more like “onboarding a new team member who actually retains everything you tell them.” If you’re using Claude Code, this often starts with a CLAUDE.md file at your project root — generated by running /init. If you're on Claude.ai, it's the Project interface, where you upload reference files directly. **Real-world example: a solo founder building a SaaS product** Imagine you’re a founder juggling marketing copy, a product roadmap, and a codebase — all at once. Without a Project, every conversation about your app starts with you typing out “okay so my product is X, our brand voice is Y, our tech stack is Z…” again. With a Project, you set this up once: Now, every conversation in that Project — whether you’re asking for marketing copy, debugging a backend route, or planning a feature — starts with Claude already knowing who you are, what you’re building, and how you like things done. No re-explaining. No drift in tone or style between sessions. Claude’s context window is enormous — up to 1 million tokens — but that doesn’t mean “bigger is always better.” A bloated CLAUDE.md file with everything you've ever written about your company adds token cost on every single request, even when most of it is irrelevant to the task at hand. **Best practice:** structure your project data with XML tags like , , and . Claude is natively trained to recognize these tags as semantic boundaries, which means it can navigate a large knowledge base efficiently instead of treating it as one undifferentiated wall of text. The biggest productivity gain doesn’t come from better prompting. It comes from never having to repeat yourself again. So now Claude *remembers* your context. But what happens when you ask it to actually *build* something? That’s where the conversation needs somewhere to live outside the chat log — which brings us to Artifacts. Artifacts are self-contained, high-value outputs — React components, Mermaid diagrams, full Markdown documents, interactive dashboards — that appear in their own dedicated window alongside your chat. You can view, edit, version, and iterate on them directly, almost like a lightweight development environment built into the conversation. **Real-world example: a content creator building a tool, not just getting an answer** Say you run a board game blog and you want a digital companion for game night. Instead of asking Claude to “explain how to track Settlers of Catan scores” — which gets you a paragraph of text you’ll forget about in five minutes — you ask Claude to *build a React-based score tracker as an Artifact*. Claude generates a working app. You click the Artifact tab. You see a live preview — input fields for each player, a running total, maybe a turn counter. Now here’s the part that makes this genuinely different from a normal chatbot exchange: you say *“Add a button to undo the last turn,”* and Claude updates that same Artifact, versioned, in place. You’re not starting over. You’re iterating on something real. **Another example: a researcher drowning in data** Instead of asking for “a text-based summary of this dataset,” a researcher can request an Artifact with a D3.js visualization — turning a static paragraph of numbers into an interactive chart they can explore, filter, and screenshot for a paper. This solves two problems at once. First, **chat clutter** — your conversation history doesn’t get buried under 200 lines of code every time you ask for a tweak. Second, **iteration friction** — you get something that feels like a live development environment, where you can see your idea take shape in real time rather than mentally compiling code in your head. Artifacts are typically single-file. If you’re building something with complex state spread across multiple files — a real multi-page app with its own backend — an Artifact is a fantastic prototyping tool, but it’s not a replacement for a full project structure. Use it for what it’s best at: turning “build a citation converter” or “make me a quick budgeting calculator” into something that exists and works, instantly, without the overhead of scaffolding a whole application. So Projects give Claude memory. Artifacts give your ideas a home. But there’s a third piece — and it’s the one most people have never even heard of. What if you could teach Claude a *procedure* once, and have it follow that exact procedure, perfectly, every time afterward? That’s what Skills are for. A Skill is a modular package — essentially a folder containing a SKILL.md file — that teaches Claude a specific, repeatable workflow. Think of it as writing down your team's standard operating procedure once, and having Claude follow it religiously, forever. This is the clever part. Skills don’t bloat every conversation with instructions you don’t need. Instead, they load in stages: This means you can have dozens of Skills sitting “dormant” without any meaningful cost, and Claude will pull the right one off the shelf exactly when it’s needed. Imagine asking Claude to “check for bugs” in a codebase. Without a Skill, you’ll get *a* response — but the depth, structure, and rigor will vary depending on phrasing, mood of the prompt, who knows what. Now imagine instead you’ve installed a systematic-debugging Skill that enforces a strict 4-step root cause protocol every time. Suddenly "check for bugs" doesn't mean "give me a vague guess" — it means *follow the exact same rigorous diagnostic process every single time*, regardless of how the request was phrased. Here’s a genuinely useful one you could build today — a Skill that summarizes uncommitted git changes before you write a commit message or open a PR: Once this exists, every time you say “summarize my changes,” Claude doesn’t improvise — it runs the diff, checks for leaked secrets, and gives you a consistent 3-bullet summary. Teach once, benefit forever. Skill description fields are truncated at 1,536 characters — so the “metadata stage” description needs to be tight and specific. The best practice here is to **build micro-skills that chain together** rather than one sprawling “mega-skill” that tries to do everything. A focused seo-audit skill and a separate accessibility-check skill, used together, will outperform one bloated website-review skill that tries to cram both in. This is where the rubber meets the road. Let’s look at four common scenarios, side by side — what most users do, why it quietly fails, and what the shift to “productivity system” thinking actually looks like. **Prompting** *The wrong way:* “Write a Python script for a dashboard.” This fails because Claude has no idea what data the dashboard displays, what framework you’re using, or what “done” looks like. You’ll get *a* dashboard — probably not *your* dashboard. *The right way:* Use structured XML tags to spell out exactly what you need: List all components. This isn't about being more polite to the AI — it's about giving it an unambiguous spec instead of a vibe. The output goes from "a guess that might work" to "a draft built to your actual spec." **Knowledge** *The wrong way:* Pasting the same 10 facts about your company, product, or codebase into every new chat. This fails because it’s tedious, error-prone (you’ll forget something eventually), and Claude has zero memory of *which version* of those facts it saw last time. *The right way:* Store those facts once in a Project’s CLAUDE.md. Now they're always there, always current, and you've eliminated an entire category of "wait, I told you that already" friction. **Workflow** *The wrong way:* Asking Claude to “check for bugs.” This fails because the depth and rigor of the response is essentially a coin flip — sometimes you get a thorough review, sometimes a surface-level glance. *The right way:* Install a systematic-debugging Skill that enforces a 4-step root cause protocol every time. Now "check for bugs" *means something specific* — a guaranteed methodology, not a mood-dependent response. **Output** *The wrong way:* Asking for a text-based summary of data. This fails because dense numerical findings buried in paragraphs are hard to actually *use* — you can’t explore them, sort them, or present them. *The right way:* Request an Artifact with a D3.js visualization for interactive analysis. Now you have something you can manipulate, screenshot, and share — not just read once and forget. **The pattern underneath all four:** the “wrong way” treats every interaction as disposable — a one-off Q&A that vanishes the moment you close the tab. The “right way” treats every interaction as an investment in a system that gets *more* valuable the more you use it. Your Project gets richer. Your Skill library gets more comprehensive. Your Artifacts become reusable tools. Compounding returns, instead of starting from zero every time. Once Projects, Artifacts, and Skills click into place, a few advanced patterns open up — worth knowing about even if you don’t use them on day one. **The 7-Phase Dev Workflow.** Some Skills, like a “superpowers” skill, can enforce an entire development lifecycle as a strict sequence: Brainstorm → Spec → Plan → TDD → Subagent → Review → Finalize. Instead of hoping Claude follows good practices, you bake the practices into the workflow itself. **Model tiering.** Not every task needs your most powerful (and most expensive) model. Route simple tasks — quick summaries, formatting — to a lighter model like Haiku 4.5, and reserve heavyweight reasoning — system architecture, complex debugging — for a model like Opus 4.8. This isn’t just about cost; it’s about matching the tool to the task. **Subagent orchestration.** A “lead agent” can spawn specialized subagents for parallel work — say, a qa-engineer subagent and a security-officer subagent reviewing the same change from different angles simultaneously, rather than sequentially. And underpinning all of this: **Connectors (MCP)**. The Model Context Protocol acts like a universal “USB-C port” for AI — letting Claude connect directly to your Jira board, your GitHub repos, or a local PostgreSQL database. Combined with **Memory** (which retains build commands and debugging insights across sessions) and **Computer Use** (still in preview, where Claude can control a desktop directly — clicking, typing, navigating), you start to see the full shape of what “productivity system” really means. It’s not one feature. It’s an ecosystem, and Projects/Skills/Artifacts are your entry point into it. Here’s the thing nobody tells you when you first sign up: **Claude was never trying to be a slightly-better chatbot.** It was built to be a system you configure once and benefit from forever — and the reason most people never see that side of it is simple. Nobody opens a chat window expecting to find a *workspace*. The biggest lesson here isn’t “use XML tags” or “install this specific Skill.” It’s a mindset shift: **stop treating every conversation as disposable.** Every time you re-explain context you’ve explained before, every time you ask for “check for bugs” instead of defining what a good bug check looks like, every time you accept a wall of text instead of an interactive Artifact — you’re leaving the other 75% of the tool on the table. Most users never unlock this not because it’s hard, but because it’s *invisible* until someone points it out. The chat box looks the same whether you’re using it as a disposable Q&A tool or as the front door to a persistent, structured system. The difference is entirely in what you bring to it. So here’s your practical first step, today: don’t open a new throwaway chat. Instead, either run /init in your terminal to generate a CLAUDE.md, or create your first Project on Claude.ai and upload the documents that define your work. Ask Claude to interview you — *"I want to set up my preferences. Interview me about my coding style, the way I like things explained, and my current projects, then help me organize this into a knowledge base."* That one conversation is the difference between starting from zero tomorrow, and starting from where you left off today. If you’ve been treating Claude like a chatbot, start by creating a Project and a CLAUDE.md file. That single change will likely improve your results more than any prompt-engineering trick. [You’re Using Claude Wrong (And It’s Not Your Fault)](https://pub.towardsai.net/youre-using-claude-wrong-and-it-s-not-your-fault-886fffecbb35) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.