DEV Community

Cover image for The `#` Prefix: Claude's Memory Feature (And Why You Don't Need It Anymore)
Rajesh Royal
Rajesh Royal

Posted on

The `#` Prefix: Claude's Memory Feature (And Why You Don't Need It Anymore)

#tutorial #claudecode #productivity #beginners

The story of a beloved shortcut, why it was deprecated, and the better approach that replaced it

From: x.com/adocomplete

Introduction

Some of the best features are the ones that feel like magic. You discover them, wonder how you ever lived without them, and they become part of your daily workflow. The # prefix in Claude Code was exactly that kind of feature.

With a simple # Always use bun instead of npm message, you could add persistent preferences to Claude's memory. Claude would ask where to save it—project-level or global—and from that point forward, it would remember. No file editing. No configuration screens. Just natural language becoming permanent memory.

But here's the plot twist: this feature was recently deprecated. And surprisingly, that's actually good news. The replacement is even more flexible, and understanding this evolution tells us a lot about how Claude Code is maturing.

The Problem (That # Originally Solved)

Every developer has preferences. Maybe you prefer pnpm over npm. Maybe you always want TypeScript strict mode. Maybe your team has naming conventions that aren't documented anywhere but everyone just knows.

Before persistent memory, every Claude session started fresh. You'd find yourself repeating the same instructions:

  • "Remember, we use tabs not spaces"
  • "Always use arrow functions"
  • "Our API endpoints follow this naming pattern..."
  • "Don't use any for TypeScript types"

This was tedious. You were essentially training Claude from scratch every single time.

The deeper problem:
Your preferences and project conventions are valuable context. They're the difference between Claude generating code that you'll accept immediately versus code that requires manual cleanup every single time.

The Original Solution: The # Prefix

The # prefix was elegant in its simplicity.

How It Worked

Starting any message with # signaled to Claude that this wasn't a regular instruction—it was something to remember:

# Always use bun instead of npm for package management
Enter fullscreen mode Exit fullscreen mode

Claude would respond:

Got it! Where would you like me to save this preference?
1. Project memory (CLAUDE.md in current project)
2. Global memory (applies to all projects)
Enter fullscreen mode Exit fullscreen mode

You'd choose, and the preference was saved. No file editing required. Natural language in, persistent behavior out.

Common Use Cases 

# Use single quotes for strings, not double quotes
# Prefer functional components over class components in React
# Always add JSDoc comments to exported functions
# Our database tables use snake_case, not camelCase
# Error messages should be user-friendly, not technical
Enter fullscreen mode Exit fullscreen mode

Each of these would become a persistent instruction that Claude would follow in future sessions.

Why It Was Deprecated

So why remove such a useful feature? The answer lies in simplicity and transparency.

The # prefix had hidden complexity:

  • Users weren't always sure what was being saved where
  • The distinction between project and global memory wasn't always clear
  • Some preferences needed to be more nuanced than a single line allowed
  • The magic sometimes felt like too much magic

The better approach:
Just ask Claude directly to update your preferences, or edit the CLAUDE.md file yourself.

The New (Better) Approach

Instead of a special prefix, you now have two natural options:

Option 1: Ask Claude Directly

Simply tell Claude what you want it to remember:

"Hey Claude, I'd like you to always remember to use bun 
instead of npm for this project. Can you add that to 
the project's CLAUDE.md file?"
Enter fullscreen mode Exit fullscreen mode

Claude will:

  1. Open or create the CLAUDE.md file
  2. Add your preference in a clear, readable format
  3. Confirm what was added

This is actually more powerful because you can have a conversation about it:

You: "Add a preference for using Tailwind CSS classes"
Claude: "Sure! Any specific guidelines? Like utility-first 
approach, avoiding @apply, or specific class ordering?"
You: "Yes, utility-first, and use the cn() helper for 
conditional classes"
Claude: [Updates CLAUDE.md with detailed preferences]
Enter fullscreen mode Exit fullscreen mode

Option 2: Edit CLAUDE.md Directly

The CLAUDE.md file is just Markdown. You can edit it yourself:

# Project Preferences

## Package Management
- Use bun instead of npm
- Lock file is bun.lockb

## Code Style
- Single quotes for strings
- Functional components only
- Always use TypeScript strict mode

## Naming Conventions
- Components: PascalCase
- Utilities: camelCase
- Constants: SCREAMING_SNAKE_CASE
Enter fullscreen mode Exit fullscreen mode

This gives you full control and complete visibility into what Claude will remember.

Pro Tips

Review your CLAUDE.md periodically:

! cat CLAUDE.md
Enter fullscreen mode Exit fullscreen mode

See exactly what Claude is remembering. Remove outdated preferences. Refine vague ones.

Be specific in your preferences:

Instead of:

- Write good code
Enter fullscreen mode Exit fullscreen mode

Try:

- Use early returns to avoid deep nesting
- Extract functions over 30 lines
- Prefer composition over inheritance
Enter fullscreen mode Exit fullscreen mode

Create team-shared CLAUDE.md files:

Commit your CLAUDE.md to version control. Now your entire team shares the same Claude preferences, ensuring consistent AI assistance across all developers.

Use sections for organization:

## Must Follow
Critical team conventions that should never be violated

## Preferences
Stylistic choices that improve consistency

## Project Context
Background information Claude should know
Enter fullscreen mode Exit fullscreen mode

Combine with global settings:

You can have a global ~/.claude/CLAUDE.md for personal preferences that apply everywhere, and project-specific ones for team conventions.

Real-World Use Case

The Scenario:
You're joining a new team. They have lots of unwritten conventions—coding style, architecture patterns, naming schemes—that aren't in any linter or formal documentation.

The Old Way (pre-# prefix):
Repeat instructions every session. Get inconsistent Claude suggestions. Manually fix generated code to match team style.

With # prefix (deprecated):
Gradually add rules: # We use feature-sliced design architecture, # All API calls go through the useQuery hook.

The New (Best) Way:

# Team Conventions for ProjectX

## Architecture
- Feature-sliced design: features/, entities/, shared/
- Each feature is self-contained with its own api/, ui/, model/
- Cross-feature imports only through public API (index.ts)

## Data Fetching
- All API calls use React Query (useQuery, useMutation)
- No direct fetch() calls in components
- Query keys follow: ['feature', 'entity', id] pattern

## Styling
- Tailwind CSS only, no CSS modules
- Use cn() helper for conditional classes
- Design tokens in tailwind.config.ts
Enter fullscreen mode Exit fullscreen mode

Commit this to the repo. Every team member's Claude now understands your project the same way. Onboarding new developers? Claude helps them follow team conventions from day one.

Conclusion

The # prefix was a clever solution to a real problem. Its deprecation isn't a loss—it's an evolution toward something more transparent and flexible. Now you have direct control over Claude's memory through the CLAUDE.md file, and you can ask Claude to update it conversationally.

The lesson here is that the best AI tools aren't about magic shortcuts. They're about giving you clear, controllable ways to customize behavior. CLAUDE.md does exactly that. It's a file you can read, edit, share, and version control. No hidden state. No mysterious memory. Just plain Markdown that makes Claude smarter about your specific needs.

So take a few minutes today to create or review your project's CLAUDE.md. Document those team conventions. Capture those preferences. Make Claude truly yours.

Coming up tomorrow in Day 6: We'll explore a new power feature that takes your Claude Code workflow to the next level. See you then!

This is Day 5 of the "31 Days of Claude Code Features" series. Follow along to discover one powerful feature every day that will transform how you use Claude Code.

Top comments (0)