What to put in AI project instructions

Quick answer

Good Project Instructions tell AI what your business does, who you serve, how your team writes, what good work looks like, and what must be checked before anything leaves the business.

Project Instructions are the difference between a generic assistant and one that feels useful inside your business.

Published: 11 June 2026.

Best for: business owners, managers, and teams setting up Claude Projects or shared AI workspaces.

Time needed: 20 to 45 minutes for a useful first draft.

What Project Instructions do

Project Instructions are the standing context for a workspace. They tell the AI how to behave inside that specific Project.

They are useful when the work repeats, such as:

• Client emails.
• Sales proposals.
• Weekly reports.
• Meeting summaries.
• Operations checklists.
• Internal knowledge support.
• Marketing drafts.
• Recruitment or onboarding material.

The point is not to sound impressive. The point is to make repeated work more consistent.

Start with the business basics

Begin with plain facts:

• What your business does.
• Who your customers, clients, or stakeholders are.
• What services or products you provide.
• What region, industry, or niche you serve.
• What your team calls things internally.
• What makes your work different from a generic provider.

If a new team member would need to know it, the AI probably needs to know it too.

Add the work this Project is for

Do not write one giant instruction set for everything.

A Project should have a job. For example:

• “Draft first-pass client emails.”
• “Turn meeting notes into internal actions.”
• “Prepare proposal outlines.”
• “Summarise support tickets.”
• “Help managers write weekly updates.”

When the Project has a clear job, the instructions become easier to write and easier to improve.

Define your voice

Tone matters because AI defaults to sounding polished but vague.

Give practical voice guidance:

• Write in plain English.
• Be warm, direct, and useful.
• Avoid hype.
• Avoid corporate filler.
• Use Australian spelling.
• Explain tradeoffs clearly.
• Do not make claims that need evidence.

Then add two or three examples of writing you like. Examples beat abstract tone words.

Add standards for quality

Tell the AI what good work looks like.

Useful standards include:

• Use headings when the reader needs to scan.
• Keep client-facing writing concise.
• Flag uncertainty instead of pretending.
• Ask before making assumptions that affect price, compliance, or client commitments.
• Do not invent facts, policies, prices, testimonials, or guarantees.
• Separate draft language from final recommendations.
• Make next steps obvious.

These rules are simple, but they prevent a lot of bad output.

Add examples and reference files

Then add examples. A good email, proposal, checklist, report, or client note is more useful than a page of abstract rules.

Good examples include:

• A strong client email.
• A proposal you would happily send again.
• A report format the team already trusts.
• A checklist that reflects the real process.
• A glossary of internal terms.
• A list of services, packages, or common questions.

Keep the reference set small at first. Too many files can make the Project noisy.

Name what needs human review

This is where many instructions are too soft.

Tell the AI which outputs must be checked before use:

• Legal, financial, medical, safety, or compliance content.
• Advice that could affect a client’s decision.
• Pricing, quote, or contract language.
• Client records or private information.
• Any claim about results, guarantees, or performance.

This does not make the AI less useful. It makes the workflow safer.

Prompt to draft Project Instructions

Copy this into Claude:

Help me write Project Instructions for this AI workspace. Ask me questions about my business, clients, services, tone of voice, repeated tasks, examples of good work, and quality standards. Then draft practical instructions that a new team member could understand and that Claude can follow inside this Project.

After Claude drafts the instructions, edit them like a business document. Remove anything vague. Add examples where the instruction is hard to explain.

A simple Project Instructions template

Use this structure:

Purpose:
This Project helps with [specific repeated workflow].

Business context:
We are [business type] serving [customers] with [services].

Voice:
Write in [tone]. Avoid [things to avoid].

Useful context:
Use the uploaded examples, templates, and reference files. If information is missing, ask before guessing.

Quality standards:
Good outputs should be clear, specific, practical, and easy to check.

Human review:
Flag anything involving pricing, compliance, legal risk, private client information, or claims that need evidence.

Common mistakes

Avoid these:

• Writing instructions that are too abstract.
• Trying to cover every task in one Project.
• Adding too many files before the workflow is clear.
• Forgetting examples.
• Forgetting review rules.
• Leaving outdated services, prices, or policies in the Project.
• Treating the first draft as permanent.

The best instructions improve through use.

Project Instructions checklist

Before you call the Project ready, check that it includes:

• The purpose of the Project.
• Business context.
• Customer or client context.
• Tone and writing style.
• Common tasks.
• Examples of good outputs.
• Reference files or templates.
• Rules for what Claude should not invent.
• Clear human-review boundaries.
• A date to review and improve the instructions.

Frequently asked questions

How long should Project Instructions be?

Long enough to be useful, short enough to maintain. A few clear sections plus strong examples usually beats a huge instruction document.

Should every team have one shared Project?

Not always. Use shared Projects for repeated team workflows. Use separate Projects when the context, files, or quality standards are different.

Do Project Instructions replace prompting?

No. They reduce repeated setup. You still need to ask clear questions inside each chat, but you should not need to re-explain your business every time.

How often should I update Project Instructions?

Review them after the first week of real use, then monthly or whenever the workflow changes.

What is the biggest mistake?

The biggest mistake is writing instructions that sound clever but do not change the output. Make them operational.

Review the instructions after a week of real use. Keep what improved outputs. Delete anything the AI ignored or misunderstood. Treat the instructions like a working document, not a plaque on the wall.