Setting Up a Project with Custom Instructions

Custom instructions are the part of a Project that does the most work with the least effort: a short block of text that Claude reads before every conversation you start inside that Project.

Summary

Setting up a Project well starts before you type a single instruction - it starts with deciding what the Project is actually for.

A Project with a clear, narrow purpose produces custom instructions that are easy to write and easy for Claude to follow consistently.

A Project with a vague purpose tends to accumulate instructions that pull in different directions, which shows up as inconsistent answers later.

This page walks through creating a Project, writing its custom instructions, and testing whether they are actually steering conversations the way you intended.

The steps below apply the same way whether the Project is for a work role, a specific writing style, a recurring analysis task, or anything else you find yourself explaining to Claude more than once.

Recipe

Quick-reference steps - the fastest path from nothing to a working Project.

In Claude.ai, open Projects in the sidebar and choose Create project.
Name the Project after its specific purpose, not its general category - "Weekly Sales Recap" instead of "Reports."
Open the Project's settings and find the custom instructions field.
Write instructions that cover three things: who the audience is, what Claude should always do, and what Claude should never do in this context.
Save the instructions, then start a new conversation inside the Project and test it with a realistic question.

When to reach for this:

You've explained the same background or rules to Claude in more than one conversation already.
A recurring task has a consistent audience, tone, or format you want applied every time.
You want new team members using Claude on a task to get consistent results without re-teaching them the context.
The task has firm constraints - things Claude must never do - that are easy to forget to restate each time.

Working Example

Here is a complete, realistic custom-instructions block for a Project meant to help draft internal support responses:

You are helping draft replies to customer support tickets for a small SaaS product called Northwind Notes.

Audience: non-technical customers, most of whom are already frustrated when they write in.

Always do: keep replies under 150 words, open by acknowledging the specific issue in the customer's own words, and end with one clear next step.

Never do: promise a refund, quote a specific fix date, or use technical jargon like "backend" or "API" without explaining it in plain terms.

Tone: warm and direct, not overly formal, no corporate boilerplate like "We value your business."

What this demonstrates:

The instructions name a specific audience instead of leaving tone to guesswork.
"Always do" and "never do" are separated, which makes hard constraints unambiguous.
The word limit and structure requirement are concrete enough that Claude can actually follow them consistently.
Nothing in the instructions tries to also cover an unrelated task, keeping the Project's purpose singular.

Deep Dive

How It Works

Custom instructions are read before your message on every new conversation started inside the Project, so they function as standing background rather than something you re-send.
They apply at the Project level, not the account level - a different Project can have entirely different, even contradictory, instructions without conflict.
Editing the instructions changes behavior going forward. It does not retroactively rewrite what already happened in past conversations.
Instructions work alongside anything you say directly in a conversation. A specific request in the chat can still override or refine what the standing instructions say for that one exchange.

Writing Instructions That Actually Hold Up

Element	Weak version	Stronger version
Audience	"Be helpful"	"Non-technical customers who are already frustrated"
Format	"Keep it short"	"Under 150 words, one clear next step at the end"
Constraints	"Don't overpromise"	"Never promise a refund or a specific fix date"
Tone	"Professional"	"Warm and direct, no corporate boilerplate"

Vague instructions tend to get quietly ignored because there is nothing concrete for Claude to check its own output against. Specific, checkable instructions hold up far better over many conversations.

Testing and Revising

After saving instructions, run at least two or three realistic test conversations before trusting the Project for real work.

Ask questions that sit near the edges of what the Project is for, not just the easiest case, since edge cases are where vague instructions tend to break down first.

If an answer misses the mark, look for the specific instruction that should have caught it and sharpen that line rather than adding a long paragraph of general guidance on top.

Gotchas

Writing instructions as a wish list instead of rules. "Try to be concise" reads as optional. Fix: state hard limits directly, like a word count or a required structure.
Packing unrelated tasks into one instruction block. Mixing "draft support replies" and "summarize sales calls" in the same Project muddies both. Fix: split them into two Projects with their own instructions.
Never testing the instructions before relying on them. Instructions that read well on paper can still produce inconsistent answers in practice. Fix: run a handful of realistic test conversations before using the Project for real work.
Letting instructions go stale. A Project's purpose can shift over weeks while the instructions stay frozen from day one. Fix: revisit the instructions whenever the Project's actual use starts to drift from what they describe.
Assuming instructions restrict what you can ask. Some people avoid asking off-topic questions inside a Project out of caution. Fix: custom instructions shape default behavior, they do not lock the conversation to one topic - you can still ask anything.

Alternatives

Alternative	Use When	Don't Use When
Plain chat, no Project	The task is a genuine one-off with no expected repetition.	You'll be asking similar questions again within days or weeks.
Retyping context each message	You need something once and don't want to set anything up.	You're repeating the same background across many conversations - it becomes tedious and inconsistent fast.
A single broad Project for everything	You're just getting started and want minimal setup.	You have several genuinely different tasks - a broad Project tends to blur instructions together.

FAQs

How long should custom instructions be?

Long enough to cover audience, required behavior, and hard constraints, and no longer. A few tight sentences that Claude can actually check its output against beats a long paragraph of general guidance.

Can I have different custom instructions for different conversations in the same Project?

Not as separate standing instructions - the custom instructions apply Project-wide. You can still give a specific conversation extra direction directly in the chat, which layers on top of the Project's instructions for that exchange.

What happens if I edit the instructions after already having conversations in the Project?

New conversations, and new messages in existing ones, follow the updated instructions. Past responses already given are not rewritten.

Should I write instructions as commands or as background information?

Both, but keep them separate. Background helps Claude understand context; direct commands ("always," "never") are what actually constrain behavior. Relying only on background without explicit rules tends to produce softer, less consistent adherence.

Is there a limit to how many custom instructions a Project can have?

There is a practical length limit to the instructions field, which varies by plan and changes over time - check your workspace's current limits in Project settings rather than assuming a fixed number.

Do custom instructions replace the need for uploaded knowledge files?

No, they serve different purposes. Instructions set behavior, tone, and rules. Knowledge files supply reference material and facts. Most well-built Projects use both together.

Can custom instructions make Claude refuse to answer certain topics?

They can steer Claude away from topics outside the Project's stated purpose, but they work as guidance, not a hard technical block. For a genuinely off-limits topic, say so explicitly and clearly in the instructions.

How do I know if my instructions are actually working?

Run a few realistic test conversations, including edge cases, after saving the instructions. If responses consistently reflect the audience, format, and constraints you wrote, they're working; if not, sharpen the specific line that should have caught the miss.

Should every team member share one Project, or should each person make their own?

It depends on whether the underlying task and rules are truly identical. A shared Project with one set of instructions keeps everyone consistent; individual Projects make sense when people apply the same general task differently.

What's the most common mistake people make when writing their first custom instructions?

Writing them too vaguely, using soft language like "try to" or "be professional" instead of specific, checkable rules the model can consistently apply.

Can I copy custom instructions from one Project to another?

You can copy the text manually into a new Project's instructions field. There is no automatic sync between Projects, so edits to one do not affect the other, which is useful when two Projects start similar but need to diverge.

Do custom instructions affect Artifacts created inside the Project?

Yes. Any Artifact Claude drafts inside a Project's conversation is produced using that Project's custom instructions and files, the same as a plain chat reply would be.

Uploading Knowledge Files to a Project - the companion setup step for reference material.
What Makes a Good Project: Scope and Shared Context - how narrow scope keeps instructions effective over time.
Project Setup Checklist: Instructions, Files, and Scope - a checklist covering this whole setup flow.
Projects & Artifacts Basics - a broader first walkthrough of creating a Project.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.