Claude Projects are the closest thing to a trained assistant you can build without writing any code. The custom instructions field lets you define Claude's role, knowledge, constraints, and communication style once — and every conversation in that project picks it up automatically. The knowledge files extend that further, giving Claude persistent access to documents you'd otherwise paste every session. This guide covers both features in depth: what they do, how to use them well, and the mistakes that undermine them.
What Custom Instructions Actually Do
When you add instructions to a Claude Project, those instructions are injected as a system-level context before every conversation. Claude reads them before your first message. Everything in the instructions shapes how Claude interprets your requests, formats responses, and makes judgment calls throughout the conversation.
The practical effect: you don't have to re-explain your context, role, preferences, or constraints every time you open a new chat. A project for contract drafting can have instructions that establish the legal tone, jurisdiction, and client type. A coding project can define the tech stack, style guide, and output format. A research project can specify what sources Claude should favor or avoid.
Instructions in Claude Projects are distinct from the broader Claude custom instructions setting in your account preferences. Account-level instructions apply across all of Claude; project-level instructions apply only within that project and take precedence within their scope. If you're managing multiple distinct workflows, projects let you have different "versions" of Claude's behavior for each one.
The Character Limit: What It Means in Practice
Claude's project instructions field has a character limit — the interface shows a live counter as you type. This limit is there for a reason: instructions that are too long dilute Claude's attention across them. The most important rules get buried under noise.
The right approach isn't to maximize characters used. It's to write dense, unambiguous instructions where every sentence does specific work. Instructions that say "be professional and helpful" waste characters on things Claude already does by default. Instructions that say "Always cite sources with author, publication, and year in parentheses — never use footnotes" are doing real configuration work.
Practical approaches when you're running out of space:
- Cut the obvious. Remove anything Claude would do anyway without being told. Default behavior doesn't need to be specified.
- Use bullets, not prose. "Respond in plain text. Use bullet points for lists. No markdown headers." is more character-efficient and more readable than a paragraph making the same points.
- Put the most important rules first. Claude weighs earlier content more heavily. The constraints that matter most should come before the nice-to-haves.
- Move context to knowledge files. Background information — company context, domain knowledge, terminology glossaries — belongs in files, not instructions. Instructions should define behavior, not provide information.
Structuring Instructions That Work
Instructions break down into a few distinct types, and keeping them organized helps Claude apply them consistently.
Role and context
Tell Claude who it is in this project and what context it's operating in. This is typically one or two sentences.
You are a senior legal assistant specializing in California employment law. You are helping Sophie, a solo employment attorney, review documents and prepare client communications.The role definition changes how Claude interprets ambiguous requests. "Is this clause enforceable?" means something different to a California employment attorney than to a general-purpose AI.
Behavioral rules
Specific, actionable constraints on how Claude should behave. These are the highest-value lines in your instructions.
- Never give definitive legal advice. Always frame analysis as "this provision may be interpreted as..." or "courts have generally held..."
- Flag any clause that contradicts California Labor Code section 2922 (at-will employment) with a [REVIEW] marker
- Ask for clarification before drafting anything — never assume the intended party or context
- Keep all responses under 400 words unless asked for a full analysisOutput format
Define what Claude's responses should look like, especially if you'll be using the output downstream (in a document, an email, a system).
Format document summaries as: Summary (3-5 bullets), Key Risks (1-3 items), Recommended Actions (numbered). Plain text only — no markdown formatting.Scope and exclusions
What Claude should and shouldn't do in this project.
Only assist with employment law matters. If asked about other legal areas, say: "This project is configured for employment law — I'd recommend a separate conversation for that topic."Knowledge Files: What They Are and When to Use Them
Knowledge files are documents you upload to a project that Claude can reference throughout conversations. You can upload PDFs, Word documents, text files, spreadsheets, and other common formats. Claude reads and indexes the content — you don't need to paste it in every time.
Good candidates for knowledge files:
- Reference documents you cite repeatedly. A company style guide, a technical specification, a product roadmap, an API reference — anything you'd otherwise copy-paste into conversations.
- Domain context. If Claude needs background on your industry, company, or subject area to give useful responses, a context document belongs in knowledge files rather than instructions.
- Templates and examples. Upload sample outputs you want Claude to match in style, format, or structure.
- Data for analysis. Reports, exports, or datasets Claude should be able to reason about across multiple conversations.
Poor candidates for knowledge files:
- Files with sensitive personal data. Claude processes uploaded content in the context of your conversations. If a document contains data that shouldn't be in a conversation, don't upload it.
- Very large files where only a small section is relevant. Claude has a context window; uploading a 200-page document when you only need one section is less effective than uploading a clean extract of that section.
- Highly dynamic data. If the information changes frequently, you'll need to re-upload updated versions. Better to paste current data when needed rather than maintain stale files.
How Claude Uses Knowledge Files
When you upload files to a project, Claude has access to their contents across every conversation in that project. Claude doesn't literally "read" them at the start of each conversation the way it reads instructions — instead, it can retrieve relevant content when your messages require it.
This means very targeted questions ("What does our style guide say about Oxford commas?") work better than expecting Claude to synthesize a large file unprompted. If you need Claude to thoroughly reference a document, say so explicitly: "Using the product spec I've uploaded, identify any requirements that conflict with this proposed feature."
When referencing uploaded content, Claude will typically note where the information came from. If it can't find something in the files, it will usually say so rather than hallucinate an answer — though you should verify important details, especially for technical or legal content.
Project Configurations for Common Use Cases
Content and writing
Instructions should define voice, format, length, and audience. Knowledge files should contain brand guidelines, tone examples, past content to reference for style matching, and any terminology rules. Include a few examples of good output in the instructions or files — Claude replicates demonstrated patterns better than described ones.
Software development
Instructions define the language, framework, coding conventions, and how Claude should handle uncertainty (ask vs. make a best guess). Knowledge files contain the tech stack documentation, existing architecture decisions, and any internal libraries Claude should know about. Keep instructions focused on output format: whether Claude should explain code, how verbose comments should be, whether it should include error handling by default.
Research and analysis
Instructions define what sources to favor or avoid, how to handle conflicting information, what citation format to use, and how Claude should flag low-confidence claims. Knowledge files contain the primary documents being researched, any background literature, and the research questions framing the project.
Customer-facing communications
Instructions define tone (formal/informal, warm/neutral), what Claude should and shouldn't commit to, how to handle complaints or sensitive topics, and any regulatory constraints on language. Knowledge files contain your products/services documentation, FAQs, approved phrasing for common scenarios, and escalation criteria.
Troubleshooting Common Issues
Claude isn't following the instructions
Check for contradictions within your instructions — Claude will try to satisfy all rules simultaneously and may produce inconsistent output if they conflict. Also check if the instructions are too vague: "be concise" is subjective; "respond in under 200 words unless the question requires a longer answer" is specific. If you have many rules, the ones at the bottom may get less attention — reorder to put critical constraints first.
Claude isn't using the knowledge files
Be explicit in your prompts: "based on the [document name] I've uploaded..." or "referring to the knowledge files in this project..." helps Claude know to retrieve that content. If the file is large, point to the relevant section. Claude's retrieval is better when you indicate what you're looking for.
Instructions conflict across account and project level
Project instructions take precedence over account-level instructions within that project. If your account instructions say one thing and your project instructions say another, the project wins. Be aware of this when you have global preferences in account settings that you want to override for specific projects.
The project works in some conversations but not others
Long conversations can push earlier instructions further back in Claude's context. If a project starts working less reliably in a very long thread, start a new conversation in the project — the instructions are re-applied fresh. Keep frequently-used projects to focused, bounded conversations rather than one endless thread.
The Core Principle
Claude Projects don't make Claude smarter — they make Claude more reliably useful for your specific work. The instructions define the constraints that keep Claude on task and in format. The knowledge files provide the reference material that keeps Claude grounded in your actual context. Together, they let you skip the setup overhead that would otherwise cost minutes at the start of every conversation.
The configuration that works is the one you'll maintain. Start with a minimal instruction set that covers the cases that matter most, and add rules when you notice gaps — not before. Over-engineered project instructions that you're constantly editing are less useful than a lean set that runs quietly in the background.
For the broader custom instructions strategy across Claude (not just Projects), see our complete custom instructions guide. For using Projects alongside Claude's other workspace features, see our Claude Projects complete guide. If you need help configuring Claude Projects for your team's workflows, we consult.