Writing Effective Project Instructions for Claude

You've created a Claude Project. You're staring at the Project instructions field. The cursor is blinking. You know this is where you tell Claude about your work, but you're not sure what to write or how much detail to include.

Most people treat Project instructions like a dumping ground. They paste their entire brand guide, list every possible task they might do, or write paragraph after paragraph explaining their organization's history. Then they wonder why Claude doesn't seem to use any of it.

Project instructions are not a knowledge base. They're not a task list. They're context that Claude should remember and apply consistently across multiple conversations within that Project.

What Project Instructions Actually Do

When you write Project instructions, you're setting persistent context. Every conversation you have inside that Project starts with Claude already knowing what you've put there. This is different from chat messages, which only exist within a single conversation thread.

Think of Project instructions as the briefing you'd give a new team member who will work with you on many different tasks over time. You wouldn't explain every single thing they might ever do. You'd give them context about the work, how you operate, and guidelines they should follow consistently.

Project instructions answer three questions:

What is this project about? Claude needs to know the domain you're working in. Are you writing fundraising appeals for a nonprofit? Creating sermon outlines? Designing social media content? Name the type of work clearly.

What should Claude know about how you work? This is where you put organizational constraints, voice guidelines, or specific approaches you always take. If your nonprofit uses person-first language, say that. If your church avoids certain theological terms, name them. If you write in AP Style, specify it.

What guidelines should Claude follow consistently? These are the rules that apply across every task in this Project. Not rules for a single task, but principles that should shape every response.

The Common Approach: Too Much or Too Little

Most people make one of two mistakes. The first is writing almost nothing, assuming Claude will figure it out. The second is writing everything, assuming more information always helps.

This tells Claude almost nothing. What kind of nonprofit? What kind of content? What does "good copy" mean to you? Claude has no context to work from, so you'll repeat the same information in every conversation.

This is reference material dressed up as instructions. Most of this information matters for specific tasks but doesn't need to persist across every conversation. Claude will have trouble identifying what actually matters.

The Better Approach: Focused Context

Effective Project instructions give Claude exactly what it needs to be useful across many conversations, without burying that information in unnecessary detail.

Start with the domain and your role. In two or three sentences, tell Claude what you're working on and what you need help with. Be specific about the type of work, not the history of your organization.

Name your constraints and guidelines. If you always follow certain rules, state them clearly. If you have voice preferences that apply to all content, include them. If certain topics are off-limits, say so.

Leave out what belongs in chat. Task-specific instructions go in your actual prompts, not Project instructions. Details that only matter once don't need to persist. Reference documents belong in Project Knowledge, not instructions.

This version tells Claude what it needs to know to be consistently helpful across many different tasks: donor appeals, social media posts, grant applications, thank-you letters. The instructions focus on principles that apply every time, not details that only matter once.

When to Add More, When to Cut

You don't need to get Project instructions perfect on the first try. Start lean. As you work, notice what you're repeating in every conversation. That repetition is a signal: this context probably belongs in the instructions.

If you find yourself starting every chat with "Remember, we use person-first language," add that to your instructions. If you keep saying "Keep it under 150 words," but the length changes with every task, leave it out and specify in each prompt instead.

Similarly, if you've written instructions that Claude never seems to use, they're probably not actually needed. Cut them. Shorter, more focused instructions work better than long ones that dilute the signal.

Instructions Versus Knowledge

Claude Projects have two places to put information: instructions and Knowledge. They serve different purposes.

Instructions are guidelines about how to work. They tell Claude what to do, how to think about the work, and what rules to follow.

Knowledge is reference material. It's the content Claude might need to look at: brand guides, past examples, data, style sheets, documentation.

If it's a rule or principle that shapes how Claude should respond, it belongs in instructions. If it's information Claude might need to reference, it belongs in Knowledge.

This distinction keeps your instructions focused on guidance rather than turning them into a filing cabinet.

Try It Today

Open a Claude Project you've already created, or create a new one. Look at the Project instructions field. Instead of trying to write complete instructions, answer these three questions in order:

1. What kind of work is this project for? Write one sentence. Be specific about the domain and what you need help with.

2. What should Claude always do or never do in this project? List 2-3 guidelines that apply across every task.

3. What information do I keep repeating in every conversation? Add that to your instructions.

That's it. Save the instructions. Start a new chat in that Project and try a task. See if Claude uses the context you provided. If something is missing, add it. If something doesn't help, remove it.