The Ultimate Guide to Claude's Project Memory: How to Build AI That Actually Knows Your Taste

The one prompt that builds project memory for you.

For the past few months, I’ve been posting 5-7x every week on LinkedIn. Over 250,000 impressions last month with just 2,400 followers.

I know some of you on Substack might cringe. LinkedIn has a reputation - endless humble brags, “grateful to announce” posts, people performing success rather than sharing anything useful.

But here’s my reality: I can’t rely on Substack alone to grow this newsletter. And honestly? LinkedIn’s been working.

Multiple posts went viral. The math almost feels unfair for such a small account.

The difference came down to one thing: the hook.

The right hook does 80% of the work. It stops people mid-scroll, makes them care enough to read, and eventually comment and share. A bad hook? Your best writing dies in silence.

Here’s the thing though - I write my LinkedIn posts with AI. It’s part of my content repurposing system. But getting Claude to write hooks that actually stop people? That didn’t come easy.

At first, Claude kept generating generic hooks. Safe. Forgettable. The kind that sound fine but don’t make anyone pause.

This happened even though Claude had read my best-performing posts. Even though it understood my voice. The outputs were fine. But “fine” doesn’t go viral on LinkedIn.

Until I started using project memory differently.

You probably know about AI memory from ChatGPT - how it remembers who you are, picks up on your patterns over time. But ChatGPT’s memory is a black box. You can’t really edit it. You can tweak your system prompt, but you don’t have direct control over what it retains and prioritizes.

Claude Projects work differently. I can edit memory directly. I can tell Claude exactly what to remember, and it carries those instructions into every conversation - not as vague context, but as decision-making criteria.

So here’s what I did:

When I noticed Claude wasn’t generating the hooks I wanted, I stopped just fixing the output and moving on. Instead, I asked Claude to adjust using a specific instruction: “Create bold statements that stop readers from scrolling and make them curious to learn more.”

Once I was satisfied with the result, I uploaded the instruction into the project memory.

For months, I’d been telling AI what I wanted, watching it give me generic outputs, fixing them manually, and repeating the cycle. The same friction kept appearing. The same fixes kept being needed.

Memory changed that. Now the instruction is permanent. Claude doesn’t forget.

But the key to building useful project memory isn’t knowing what to store upfront. It’s paying attention to friction.

The problem is that you can’t notice friction until you know your own taste.

That’s the real work. Not configuring AI. Understanding what you actually want - what “good” looks like to you - so clearly that you recognize when AI misses it.

Let me explain.

---

💡 Quick pause before we go deeper: I’m running Black Friday deals—30% off the yearly plan for AI Maker Labs. So if you’ve been on the fence, if you’ve been thinking about Maker Labs but never pulled the trigger, this is it 👇

$67.20 for a year. Ends next Monday, Dec 1st. Access to every implementation blueprint I create for the next 12 months. Here’s what you’ll get right out of the gate.

---

What most people do wrong building Claude Projects

Most people start with the system prompt - which is correct. You document your voice, preferences, audience, tone, background information. Every instruction you can think of.

I wrote a practical, in-depth guide on building Claude’s project knowledge if you want the full method.

The Ultimate Guide to Turn Claude Into Your Brain’s Most Valuable Co-Worker

This feels productive. More detail should mean better outputs, right?

And then the outputs still feel off. Not wrong exactly, just not yours.

So you add more. More examples. More clarification. The prompt gets longer, trying to cover every edge case.

I did exactly this.

It helped. But there was still a gap. Outputs that technically followed instructions but didn’t feel like me. Patterns I kept correcting manually.

The problem wasn’t the system prompt. The problem was I didn’t actually know what I wanted until I saw what I didn’t want.

That’s where project memory changes everything.

A system prompt is your starting point - your best guess before you start working together. Project memory is what you learn through the work. The instructions you couldn’t have written upfront because you didn’t know you needed them yet.

The system prompt is your hypothesis. Project memory is your evidence.

And the signal that tells you what to add? Friction.

Friction-Driven Memory: How to Teach AI Your Preferences

So what exactly is friction?

Friction is the gap between what Claude gives you and what you actually needed. That feeling when you read Claude’s output and think:

“This is fine, but it’s not right.”

Most people fix it and move on.

Claude writes a generic hook? Rewrite it manually. Claude sounds too academic? Simplify it yourself. Problem solved. Next task.

But that friction is coming back. Tomorrow. Next week. Every time you work on something similar.

Because Claude doesn’t know it made a mistake. You fixed the output, but you didn’t fix the root cause.

By the third time you’re fixing the same issue, you know it’s a pattern worth addressing. And the corrections you make reveal preferences you couldn’t have articulated upfront - you didn’t know you hated that hook structure until Claude used it.

This only works if you can feel the friction in the first place. You need enough clarity about your preferences to recognize when Claude misses them. But you don’t need perfect taste - you just need to notice when something feels off.

That sensitivity develops through practice. The more you work with Claude and pay attention to what you change, the clearer your preferences become.

The System: Build Your Claude Project Memory Step by Step

So you feel the friction. Now what?

Here’s the process I use to turn friction into permanent project memory.

Step 1: Notice friction in real-time (don’t just fix it)

You’re working with Claude. Something in the output bothers you. Your instinct is to fix it quickly and keep moving.

Stop.

That moment of friction is valuable. If you fix it and move on, you lose the data.

Instead, pause and ask yourself: “What specifically is wrong here?”

And get specific:

• Is it the tone? Too formal? Too casual? Too academic?

• Is it the structure? Wrong order? Too long? Missing something?

• Is it a pattern? A phrase structure you hate? A rhetorical device that feels forced?

The more specific you can name the friction, the more useful it becomes.

---

Step 2: Translate friction into instruction

Here’s where the real work happens.

Friction is a feeling. Project memory needs language. Your job is to translate one into the other.

I use this simple framework:

• What I got: [Claude’s actual output]

• What I needed: [What would have been right]

• The gap: [What’s the difference between these two?]

• The instruction: [What would I tell Claude so this doesn’t happen again?]

---

Step 3: Add to Project Memory

Now you take that instruction and make it permanent.

In Claude Projects, you can add to memory directly in conversation. Before updating them, I usually say something like:

“I noticed the hook you wrote explained the concept before revealing the insight. I need hooks that lead with the surprising claim first. Can you help me write a memory instruction that captures this preference?”

Claude is actually great at helping you articulate your preferences once you’ve identified the friction.

A few principles for good memory entries:

Be specific, not vague.

• Bad: “Write better hooks”

• Good: “Lead with the insight first. Don’t set up context before the revelation.”

Include examples when helpful.

• Don’t write: ‘Here’s a feature, many people don’t use it, but there’s a pattern...’

• Do write: ‘You don’t know what your project needs until it fails.’

Name the pattern you’re avoiding.

• Avoid the ‘They won’t be X, they’ll be Y’ rhetorical contrast pattern.

And make them actionable. Claude should be able to read the instruction and immediately know what to do differently.

---

Step 4: Test and refine

Memory added. But does it work?

Next time you’re in a similar situation, pay attention. Did Claude follow the instruction? Did the friction disappear?

If yes: Great. Move on and wait for the next friction point to surface.

If no: The instruction probably wasn’t specific enough. Refine it.

Sometimes I’ll add a memory entry and Claude still doesn’t quite get it. That usually means my instruction was too vague or didn’t capture the real issue. The friction repeating is just more data - it’s telling me to be more precise.

This isn’t a one-and-done process. It’s iterative. Your project memory grows and sharpens over time as you encounter more friction and get better at translating it.

The Friction-Detection Shortcut

Now that you understand the process, here’s how to speed it up. Sometimes you’re in the middle of a conversation with Claude, making edits and adjustments as you go. You tweak a sentence here. Rewrite a hook there. Ask for a different angle.

You’re in flow. You’re just fixing things without thinking about it.

But Claude is noticing.

Claude can see the pattern of your corrections even when you’re too focused to spot it yourself. Every time you adjust something, Claude is tracking what changed and why.

So here’s the trick: ask Claude to tell you what it’s noticing.

During conversation, drop in this prompt:

“Looking at our conversation so far, are there any patterns in how I’ve corrected your outputs or asked you to adjust things? What preferences or rules am I demonstrating that aren’t captured in your system prompt or project memory yet?”

Why this works:

• Claude has perfect recall of the conversation. You might forget you adjusted tone three times in a row, but Claude doesn’t.

• It surfaces blind spots. Friction you didn’t consciously notice gets named and identified.

• It does the translation work for you. Instead of manually converting friction into instructions, Claude drafts the memory entries based on observed patterns.

This is the easiest entry point into friction-driven memory. You don’t need to do anything different - just work normally with Claude, then pause and ask what patterns it’s seeing.

Alternative prompts to try

Depending on what you’re working on, here are variations:

• After making several corrections: “I’ve made several edits to your outputs in this conversation. Can you identify the pattern and suggest a memory instruction that would prevent this friction next time?”

• For comprehensive analysis: “Based on how I’ve responded to your outputs today - what I kept, what I changed, what I asked you to redo - draft 2-3 specific memory instructions that would improve our collaboration.”

• Quick check-in during work: “Pause. Have I been correcting the same type of thing repeatedly in the last few chats? If so, what memory instruction would fix it?”

Use whichever feels most natural to your workflow.

The key is making this a habit: when you notice yourself editing Claude’s outputs multiple times in one session, pause and ask Claude to spot the pattern.

The cycle in practice

Here’s what this looks like day-to-day:

Option A (Quick): Work normally → Use friction-detection prompt → Add suggested memory entries

Option B (Detailed): Work normally → Notice friction → Translate into instruction → Add to memory → Test

Most of the time, I use Option A. It’s faster and Claude does the pattern-recognition work.

But when I hit friction that’s hard to articulate, I use Option B. The manual translation process forces me to think through exactly what I want - which often reveals preferences I didn’t know I had.

Over time, your project memory becomes a detailed map of your taste - translated into language Claude can actually use.

And here’s the beautiful part: the friction decreases.

Not because you’re lowering your standards. Because Claude is genuinely learning what you want. The first draft gets closer to your taste. The edits get smaller. The back-and-forth shrinks.

This is where AI gets better at understanding your taste.

Claude Project Memory in Practice: Real Examples

Let me show you exactly how this works with real example from one of my projects.

1. The LinkedIn hook problem

The Situation:

I’m generating LinkedIn posts. I need hooks that stop people from scrolling - bold, specific, curiosity-driven statements that create immediate tension.

But Claude keeps writing explanatory hooks. Setup before payoff. Context before revelation.

The Friction:

I’m writing a post about how enterprises are choosing AI vendors. It’s based on data showing Anthropic’s rapid enterprise market share growth.

Claude gives me:

“The AI race is heating up. Companies are making important decisions about which AI providers to use. But the patterns emerging might surprise you.”

This is backwards. Too much setup. No tension. No specificity. The reader doesn’t feel compelled to keep reading.

I rewrite it manually:

“Anthropic just ate 20% of OpenAI’s enterprise market in 24 months. And it’s not even close to done.”

Bold claim. Specific data. Immediate tension. Now you want to know how this happened.

The Translation:

I use the friction-detection prompt mid-conversation:

“I’ve adjusted several hooks in this conversation. What pattern are you noticing in my edits?”

Claude responds:

“You consistently move the insight to the front and remove all setup language. You want readers to encounter the surprising claim immediately, then build context after you have their attention. The current system prompt doesn’t explicitly prioritize this structure for hooks.”

The Memory Entry:

Hook Framework (LinkedIn):
- Lead with the insight or surprising claim FIRST
- Don’t explain or set up context before the revelation
- Structure: Insight → Context → Explanation
- Make readers think “Wait, what?” before “Oh, I see”
- Avoid: “Here’s X. Most people don’t Y. But there’s Z...”
- Instead: Lead with Z immediately

Example of what NOT to do: 
“The AI race is heating up. Companies are making decisions. But patterns might surprise you.”

Example of what TO do:
“Anthropic just ate 20% of OpenAI’s enterprise market in 24 months.”

The Result:

Next drafts come with compelling hooks instead of explanations. Claude stops easing readers in and starts stopping them mid-scroll.

The hook for my next post about AI workflow adoption came through clean on the first try.

That’s the memory working.

2. The “Tool-Name Creep” Problem

The Situation:

I’m generating Substack Notes - short social media posts that need to be universal and relatable to anyone using AI, regardless of which specific tools they’re using.

My strategy: focus on transformations and principles, not tool features.

But Claude keeps mentioning specific tool names, which makes insights feel exclusive to users of that particular tool.

The Friction:

I brief Claude on my Substack Notes strategy, including the “stay universal” principle.

Claude outputs:

“Cursor just changed how I think about coding. Instead of fighting syntax, the AI handles boilerplate and I focus on logic.”

The insight is solid. But mentioning “Cursor” by name makes it feel like it’s only relevant to Cursor users. My whole strategy depends on keeping insights portable across any AI tool.

I edit it manually:

“Programming became collaborative. The AI handles syntax patterns, I focus on problem-solving logic.”

This happens on 4 out of 10 generated notes.

The Translation:

I use the friction-detection prompt:

“I keep removing tool names from the notes you generate. Can you identify the pattern and suggest a memory instruction?”

Claude responds:

“You’re consistently removing specific tool mentions (Cursor, NotebookLM, Claude) and replacing them with universal descriptions of the transformation. This makes insights work for anyone using AI, not just users of specific tools. The current guidelines mention staying universal, but they don’t explicitly prohibit tool names.”

The Memory Entry:

Substack Notes Strategy - Universal Insights:
NEVER mention specific AI tools by name (Cursor, Claude, NotebookLM, ChatGPT, etc.)

Focus on transformations, not tools:
- Instead of “Cursor made me think in systems” → “Thinking in systems changed everything”
- Instead of “Claude taught me to code” → “Programming became collaborative”
- Instead of “NotebookLM synthesized my research” → “Research turned into frameworks”

Your audience is “people using AI” not “people using specific tools.”
Make insights portable. Keep content about universal principles, not tool features.

Test: Would this note still resonate if the reader uses different AI tools? If not, rewrite.

The Result:

Generated notes are immediately shareable without editing. They work for my entire audience, regardless of which AI tools they’re using.

No more manual culling for tool-name creep. The notes stay focused on the transformation, which is what makes them relatable and shareable.

3. The “Sales email sounds to corporate” problem

The Situation:

I’m writing a Black Friday promotional email for my AI Maker Lab premium tier. I need to drive conversions, but I can’t sound like every other marketing email in people’s inboxes.

My voice is optimistic but honest. Direct but not pushy. I want readers to feel conviction, not manipulation.

But Claude keeps defaulting to typical marketing hype.

The Friction:

I ask Claude to write urgency for the Black Friday deadline.

Claude outputs:

“🔥 LAST CHANCE! Don’t miss out on this incredible opportunity! This deal won’t last forever - grab it now before it’s gone! 🚨”

I physically cringe reading this. It sounds like every spam email I delete without opening. My rule is simple: If I wouldn’t open it, I wouldn’t bother using it.

I rewrite it:

“This ends Monday, then we’re back to full price. You’re either subscribing now or waiting another year for this offer.”

Direct. Honest. Still urgent, but it sounds like me - not like a marketing automation template.

This happens on three different sections of the same email. Claude keeps injecting hype where I want conviction.

The Translation:

After the third rewrite, I pause:

“I keep removing hype language and emojis from the sales copy. What pattern are you seeing in my edits?”

Claude responds:

“You’re replacing manufactured excitement (’Don’t miss out!’ ‘Incredible opportunity!’) with direct, honest urgency (’This ends Sunday’ ‘You’re either subscribing now or waiting’). You maintain conviction about the value without sounding desperate or salesy. The current instructions don’t distinguish between authentic urgency and typical marketing hype.”

The Memory Entry:

VOICE CALIBRATION FOR SALES/PROMOTIONAL CONTENT:
When writing any sales or promotional emails (Black Friday, product launches, conversion campaigns):

MAINTAIN (Authentic conviction):
✅ Direct challenge: “You’re either subscribing now or waiting another year”
✅ Honest urgency: “This ends Sunday, then we’re back to full price”  
✅ Confident value statement: “I know Maker Labs delivers real value”
✅ Personal vulnerability: “This only works if you actually implement”
✅ Optimistic but realistic tone: Balance possibility with honesty

AVOID (Typical marketing hype):
❌ Hype energy: “🔥 LAST CHANCE 🔥”
❌ Typical marketing urgency: “Don’t miss out!”
❌ Manufactured excitement that doesn’t match contemplative style
❌ Corporate/salesy language that loses authentic voice
❌ Overselling or exaggeration

Core principle: Keep optimistic voice and conviction WITHOUT sounding salesy. 
The line is: authentic urgency and honest value vs. manufactured hype.

The Result:

Next promotional email comes through without a single emoji or “Don’t miss out!” The urgency lands by being direct instead of desperate.

That’s the difference between AI that mimics marketing templates and AI that understands your actual voice - even when you’re selling.

Using Claude’s Knowledge Base for Deeper AI Memory

Once you begin building project memory, you’ll eventually hit a threshold.

The current interface for adding memories limits entries to a few sentences. Some items fit into a single concise paragraph of instruction; others don’t and require more detailed frameworks.

Take my sales voice calibration example from earlier. I could write:

“When writing sales emails, avoid corporate hype and maintain authentic voice.”

But here’s what that instruction doesn’t capture:

• What exactly counts as “corporate hype” vs. “authentic urgency”?

• Where’s the line between conviction and desperation?

• How do I handle limited-time offers without sounding manipulative?

The memory interface lets you write several paragraphs. But trying to document an entire voice calibration framework with examples, edge cases, and decision trees. That’s going to get messy.

This is where project knowledge base files become essential.

Think of it this way:

• Project memory = Active instructions Claude applies in every conversation

• Knowledge base files = Reference frameworks Claude consults when needed

Memory entries should be concise pointers: “Do X, reference Y framework, avoid Z pattern.”

Knowledge base files should be comprehensive documentation: detailed examples, edge cases, before/after comparisons, decision trees, as you can see based on the example section earlier.

Here’s what you can do: ask Claude to create the memory for you, generate it as a Markdown file, and upload it to your project knowledge base.

This way, whenever I ask Claude for a sales email, it will mirror my authentic voice and reference the project files for detailed frameworks.

Memory entries force you to distill your taste into clear principles. Knowledge base files let you provide depth without clutter.

The combination is more powerful than trying to cram everything into memory fields or hoping Claude remembers from past conversations.

Concise instructions pointing to detailed references. That’s the system.

To help you improve your taste and understand project memory better, you might want to check out these valuable posts:

1. The 3-Document System: How I Stopped Losing My Best Ideas Across 100 AI Conversations by Ilia Karelin

2. Reverse-engineer yourself before you train your AI by Mia Kiraki 🎭

3. Why Your Writing Breakthroughs Keep Disappearing by Greg Wolford

What Training AI Your Writing Style Actually Teaches You

Here’s what I didn’t expect when I started building project memory through friction:

This process teaches you how your own taste actually works.

Most people think they know what they want. They have vague preferences: “I like conversational writing” or “I want compelling hooks” or “Keep it simple.”

But those aren’t actionable. They’re directions without coordinates.

Friction forces you to get specific.

When Claude writes something that doesn’t match your taste, you can’t just say “that’s not right” and move on. You have to articulate why it’s not right. You have to name the specific thing that bothers you. You have to translate a feeling into language.

And that’s hard.

It’s hard because most of us haven’t consciously examined our preferences before. We just know what we like when we see it.

But building project memory requires you to reverse-engineer your own taste. To spot patterns in what you keep versus what you change. To notice the invisible rules you’ve been following without realizing they existed.

This is meta-learning through friction feedback.

You’re not just teaching Claude. You’re teaching yourself.

Where to go from here

So here’s where you start:

This week, open a Claude Project. If you already have one, pick the one you use most often.

As you work, pay attention to friction. When you find yourself editing Claude’s outputs, pause. Don’t just fix it and move on. Notice what you’re changing and why.

✅ Use the friction-detection prompt.

Let Claude tell you what it’s noticing. Then take one of those patterns and add it to project memory.

Start small. You don’t need to document everything at once. One memory entry this week is enough. One friction point identified and translated into an instruction.

Next week, add another. And another. Over time, your project memory becomes a detailed map of your taste - built through real experience instead of imagination.

---

What you’ll notice

Claude’s outputs will start matching your taste more closely. But the real value is that you’ll understand your own taste more clearly than before. The process of translating friction into instructions sharpens your judgment about your own work.

You’re not just configuring AI. You’re developing creative self-awareness.

That’s the unlock.

The bottom line

Project memory isn’t about storing information. It’s about translating taste into language AI can follow.

And the signal that tells you exactly what to translate? Friction.

You can’t know what your project needs until it fails. But when it fails - when Claude outputs something that doesn’t match your taste - that friction is telling you exactly what instruction to add next.

Don’t ignore it. Don’t just fix it and move on.

Use it.

Because friction isn’t a bug in the system. It’s the system.

It’s how taste becomes teachable. It’s how collaboration improves. It’s how you build AI environments that actually work the way you think.

So stop trying to document everything upfront. Stop wondering what you should memorize.

Start working. Notice friction. Translate it into memory. Watch what happens.

That’s how you build project memory that compounds its value over time.