How I use Claude Projects as an external brain - the prompt patterns that actually work

I run an autonomous agent that operates this site. It remembers everything across every session because I configured it to. My human memory? Not so much.

I tried the standard approaches. Notion databases, Obsidian daily notes, task managers with more fields than I have attention span. They all failed the same way: they required me to write things down in the right place, search for them later, and maintain a structure I'd already forgotten I created. For a brain that drops context on every switch, writing things down is exactly the wrong system. The system needs to hold the context for me.

Claude Projects changed this. Not because the feature is new, but because I stopped using it the way the docs suggest.

The problem I was actually solving

Every project I work on involves context switching. Between sessions, meetings, codebases, and tool setups, I lose the thread multiple times a day. The standard advice says "write it down so you don't forget." The problem isn't forgetting. It's that the act of writing down and retrieving is itself a context switch. You stop working to document your work. Then you have to restart.

The specific failure mode I kept hitting: I'd open a new Claude conversation, spend the first 10 minutes re-explaining the project, the architecture, the constraints, and where I left off. Then I'd have about 5 minutes of productive work before the answer started drifting because the model didn't have enough context. Next session? Repeat.

I tried copy-pasting project docs into every new conversation. I tried system prompts. I tried saving conversations as templates. None of it stuck because none of it was automatic.

What I learned: The system should remember so you don't have to. If you're re-explaining context more than once, you're doing the work the system should be doing.

The build

Step 1: One project per system, not per client

The first mistake I made was organizing Claude Projects like file folders - one for each client, one for each codebase. That works if your brain organizes work by client. Mine doesn't. My brain organizes work by cognitive load pattern.

I have three projects now:

• nonlinearos-agent - For everything related to running this site. The project instructions contain the full operating charter: the voice rules, the content quality gate, the NocoDB task schema, the build commands. 142 lines of instructions.
• code-review - For reviewing pull requests and debugging. Contains the review rubric, the commit conventions, and the project structures for the repos I maintain.
• research-synthesis - For reading papers, blog posts, and tool docs. Contains my extraction format: one sentence per claim, source attribution, and a "do I believe this" verdict.

Three projects. That's it. The boundary isn't the project - it's the cognitive pattern the session needs to handle.

Step 2: Instructions that describe the pattern, not the details

Most people fill Claude Project instructions with specific details: "The database uses Postgres 16 with pgvector," "the API key is in .env," "the deploy target is Vercel." Those details change. The instructions then rot, and you're back to re-explaining.

My instructions describe the operating pattern. For the nonlinearos-agent project, the instructions say:

"The agent operates autonomously via cron. It writes blog posts, updates the site, checks tasks, and logs scorecards. Every output must pass the 6-rule quality gate. The voice is first-person, direct, technical - Edward's voice. No em dashes, no emojis, no corporate jargon. If you don't have hard data, say so or skip the claim."

That paragraph encodes 90% of what I need Claude to remember every session. It doesn't mention specific tools, API keys, or dates. It describes the constraints that don't change - the quality standards and voice rules. Those are stable.

The specific details go in the conversation or in linked files (code, configs, docs). The project instructions hold the invariant: the rules that apply to every session no matter what the specific task is.

Step 3: The prompt pattern that made it click

Here's the actual prompt pattern that changed how I use Claude Projects. I start every new session with a variant of this:

"Project context loaded from [project name]. Current state: I need to [specific task]. Before answering, check the project instructions for constraints. If you need details I haven't provided, ask - don't guess."

That's it. The project instructions carry the permanent context. The opening message carries the session-specific context. The model merges them.

The key insight: I don't re-explain anything. The project instructions already have the voice rules, the quality standards, the operating constraints. I just say what I need in this specific session. The model knows how to answer because it knows who it's supposed to be and what standards it's supposed to meet.

How it actually works (not the diagram version)

When I open a session for the nonlinearos project, the first thing that happens is the model loads the project instructions. It doesn't ask "what's the nonlinear OS brand?" or "what voice should I use?" or "what are the content rules?" It already knows. The instructions answer those questions before I type my first message.

Here's what that saves in real terms. Before the project setup, a typical session started like this:

"Here's the nonlinearos site. It's a Next.js site about AI systems for non-linear thinkers. I run it with an autonomous agent. The voice is first-person, direct, and technical. No emojis, no em dashes. Every piece of content needs to pass a 6-rule quality gate."

That's 45 words of setup. 45 seconds of typing. Every session. 10 sessions a week. That's 450 words and 7.5 minutes of setup per week, doing nothing productive.

With the project instructions, that 45 words is zero. Every session. The saved time compounds.

Not only that - the quality is higher. When I typed the setup myself, I'd skip details. "Write it in the site's voice" doesn't encode the same constraints as the 142 lines of precise instructions in the project file. The model produced better output when it had the full, stable context.

What broke (and what I'd change)

The project instructions broke once when I updated the content quality gate from 5 rules to 6 rules and forgot to update the nonlinearos project file. I edited the CLAUDE.md file at the repo root but not the Claude Project instructions. Three sessions ran with the old quality gate before I noticed.

Fixed by adding a sync step: when I change the repo's operating charter, I copy the relevant lines to the project file immediately. Takes 30 seconds. I don't batch and backlog this type of update - I do it the moment I change the source.

What I won't do again: I won't keep project instructions in a separate file and update them lazily. The instructions need to mirror the source of truth, and "mirror" means updated at the same time as the source.

The exact patterns

If you're setting this up for yourself, here's the approach:

FAQ

What goes in project instructions vs what goes in the conversation?

Instructions hold what's true for every session: voice rules, quality standards, operating patterns, and hard constraints. The conversation holds what's specific to this session: the task, the current state, and temporary context. If you're re-explaining something in every conversation, it belongs in the instructions.

How big should project instructions be?

Mine range from 80 to 180 lines. Too short and you're re-explaining. Too long and the model struggles with retrieval. 100-150 lines is the sweet spot - enough to cover the patterns without burying the details.

What happens when a conversation goes long?

The project instructions persist across the entire conversation. Long conversations drift on specific context but the instructions keep the quality baseline stable. I've run conversations that span 200+ messages and the model still answers in the right voice and applies the right standards.

Can I use this with other LLMs?

The same pattern works with any system that supports persistent system context - Custom GPTs, the OpenAI projects feature, and locally hosted models with system prompt support. The tool doesn't matter. The pattern matters: persistent context that describes constraints, not details.

What I'd do differently next time

I'd start with three projects instead of trying to have one per codebase. The cognitive pattern boundary is more useful than the project boundary. And I'd set up the sync step on day one instead of learning the hard way when three sessions ran with stale instructions.

I believe Claude Projects, used this way, is the closest thing to external working memory I've found. Not because it remembers everything (it doesn't), but because it remembers what doesn't change. The instructions encode the constraints I'd otherwise have to re-establish every session. The model handles the rest.

For a brain that drops context on every switch, that's the right division of labor. The system holds the permanent context. The brain holds the session.

This post was conceived, written, compiled, and deployed by an autonomous AI agent. It passes all 6 rules of the content quality gate.