Configuring Projects
Creating a Project
To create a Project:
- In the claude.ai interface, click + New Project in the left sidebar (or navigate to Projects from the top menu).
- Give the Project a name that clearly identifies its purpose and audience. Examples: "Legal — Contract Review", "HR — Job Description Drafting", "Finance — Board Report Writing".
- Add a description (optional but useful for governance — explains the Project's purpose to other admins).
- Click Create Project.
The Project is now created with no configuration. You will be taken to the Project's settings screen where you add system instructions, knowledge and members.
Writing effective system instructions
System instructions (sometimes called the system prompt) are the most important part of a Project configuration. They define Claude's behaviour for every conversation in the Project.
A well-written system instruction has four parts:
1. Role and context
Tell Claude who it is and what context it is operating in:
You are a contract review assistant for [Company Name]'s legal team. You support solicitors and in-house counsel in reviewing commercial contracts, flagging risks, and drafting suggested redlines.
This establishes the persona and scope. Claude will not drift into unrelated tasks because the context is clear.
2. Task definition
Describe what Claude should do:
When a user shares a contract or contract clause, you should:
- Identify the key commercial terms (payment, liability, IP, termination)
- Flag clauses that deviate from our standard positions (defined in the knowledge file)
- Suggest alternative language where a clause creates unacceptable risk
- Format your response with: Risk Level (High/Medium/Low), Key Issues, Suggested Redlines
This gives Claude a consistent structure to follow for every analysis.
3. Constraints and prohibitions
Tell Claude what not to do:
Do not provide formal legal advice or represent that any analysis constitutes legal advice. Always note that your analysis should be reviewed by a qualified solicitor before relying on it. Do not include client names or matter numbers in your responses. Do not speculate about the other party's intentions.
Constraints prevent Claude from doing things that would create liability or breach your policies.
4. Output format and style
Define the format of responses:
Use clear headings. Use bold text for risk flags. Limit responses to 500 words unless the contract is complex, in which case ask the user whether they want a detailed or summary analysis.
Consistent formatting makes Claude's outputs more usable and predictable.
Full example: HR job description Project
You are a Job Description Assistant for [Company Name]'s HR team. You help HR Business Partners and hiring managers write accurate, attractive, inclusive job descriptions.
When a user provides a role title and key responsibilities, you should:
- Draft a complete job description in [Company Name]'s standard format (defined in the knowledge file)
- Use inclusive language: avoid gendered terms, age references, and requirements that are not genuinely necessary for the role
- Flag if any requirement appears to be a proxy for a protected characteristic
- Keep required qualifications to the minimum necessary
Do not include salary ranges unless the user explicitly provides them.
Do not speculate about team composition or headcount.
Do not include location requirements unless the user specifies them.
Format: use the standard template from the knowledge file. If no template is provided, use: Job Title, Team, Location, About the Role, Key Responsibilities, What You Bring, What We Offer.Adding knowledge files
Knowledge files are documents you upload to a Project that Claude can reference in every conversation. Common uses:
- Policy documents (e.g., HR policy, acceptable-use policy)
- Templates and standards (e.g., contract playbook, brand guidelines, coding standards)
- Reference material (e.g., product catalogue, pricing guide, glossary)
- Past examples (e.g., strong proposals, annotated case studies)
To add a knowledge file:
- In the Project settings, click Add files or drag and drop files into the knowledge section.
- Supported formats include PDF, Word (.docx), plain text, and Markdown. Check the current file size limits in the interface (typically 10–50 MB per file).
- After uploading, verify that Claude can reference the file by starting a conversation and asking: "What does the [document name] say about [topic]?"
Knowledge file best practices:
Keep knowledge files up to date. If your brand guidelines change and you do not update the Project, Claude will continue applying the old guidelines. Create a reminder to review knowledge files quarterly.
Do not upload files containing personal data of individuals (employee records, client PII) unless you have a clear justification and have considered the retention implications (the file contents are stored in Anthropic's systems for the Project's lifetime).
Split large documents. A 200-page policy manual is harder for Claude to navigate than 10 focused 20-page sections. Split documents by topic where possible.
Model selection
In Project settings, select the model appropriate for the task:
- Fast model (Haiku or equivalent): high-volume, simple tasks. Customer support response drafts, quick summaries.
- Standard model (Sonnet or equivalent): most business writing and analysis. This is the right default for 80% of Projects.
- Frontier model (Opus or equivalent): complex reasoning, detailed legal analysis, nuanced judgment calls. Use sparingly — the cost difference is significant at scale.
Testing your Project
Before sharing a Project with its intended members, test it thoroughly:
- Start a conversation in the Project with a realistic task.
- Verify that Claude follows the system instructions (correct format, correct constraints).
- Test edge cases: what happens if a user tries to ask something outside the Project's scope? (Claude should politely decline or redirect.)
- Verify that knowledge files are being referenced correctly.
- Test with a user who is not an admin — create a test account or ask a trusted colleague to try it — to see the experience from a member's perspective.
Scenario: testing reveals a gap
An IT admin at an insurance company creates a Claims Support Project for the customer service team. The system prompt tells Claude to help draft responses to customer claims enquiries. During testing, the admin asks: "What is the customer's policy number?" Claude responds with a fabricated policy number.
This is a hallucination risk. The admin updates the system prompt to add: "Do not invent or guess customer data. If you do not have specific customer information, say so and instruct the user to look up the information in the claims system." The admin re-tests and confirms Claude now correctly declines to fabricate data.
Key takeaway
A Project configuration is a system you are deploying, not just a setting you are toggling. Write system instructions with the same care you would give to any business process document: be specific about what to do, what not to do, and how to format outputs. Test before releasing to members.
📖 Official Documentation See this in practice in Anthropic’s live support docs: