Claude Project Instructions: How to Write Them, With Examples
Summary
- Claude Project Instructions are your project-level rules: what Claude should do, how it should write, and what it must avoid.
- Good instructions separate stable rules (voice, constraints, definitions) from per-task prompts (the specific request today).
- Use a clear structure: role + goals + audience + style + process + constraints + output format + examples.
- Include “edge-case” guidance (unknowns, ambiguity, safety boundaries) so Claude fails gracefully instead of guessing.
- You can maintain a reusable instruction library in CopyCharm to quickly paste consistent project rules into Claude and other tools.
Write Claude Project Instructions that define role, audience, style, constraints, and output formats so Claude produces consistent work across a project.
What “Claude Project Instructions” are (and what they are not)
Claude Project Instructions are the persistent, project-level directions you want Claude to follow across many chats or tasks within the same project. They are where you put the rules that should stay true even as the day-to-day requests change.
They are not the same as a single prompt for one task. A one-off prompt asks for a specific deliverable (“Draft an email to a customer about X”). Project Instructions define the operating system for the project (“Use our brand voice, follow these compliance rules, format outputs like this, ask clarifying questions when needed”).
Because Claude’s UI and plan details can vary, treat Project Instructions as a concept: a stable instruction block you maintain and reuse, whether you store it inside Claude’s project settings (if available to you) or keep it externally and paste it in when needed.
What to include in Claude Project Instructions (a practical template)
A reliable instruction set is specific enough to guide decisions, but not so rigid that it blocks normal work. Use the sections below as a starting template and keep only what your project truly needs.
1) Role and scope
Define what Claude is doing in this project and what is out of scope.
- Role: “You are a technical editor for B2B SaaS documentation.”
- Scope: “Focus on user-facing docs and release notes; do not write legal terms.”
2) Audience and reading level
Tell Claude who the reader is and what they already know.
- “Write for US-based small business owners with basic accounting knowledge.”
- “Assume the reader is a developer familiar with REST APIs.”
3) Voice, tone, and style rules
Make style rules testable. Avoid vague instructions like “make it engaging” unless you define what that means.
- Voice: “Clear, direct, practical. Avoid hype.”
- Reading flow: “Use short paragraphs, descriptive headings, and bulleted steps.”
- Language: “Use US English. Avoid idioms that don’t translate well.”
4) Definitions and “project truth”
If your project has terms that Claude must use consistently, define them once here.
- “‘Customer’ means a paying account owner; ‘user’ means any seat on the account.”
- “‘Trial’ refers to the 14-day evaluation period (do not call it ‘free plan’).”
5) Process rules (how Claude should think and work)
These rules reduce rework by telling Claude what to do when information is missing or ambiguous.
- Clarify: “If key details are missing, ask up to 5 clarifying questions before drafting.”
- Assumptions: “If you must proceed, list assumptions explicitly under an ‘Assumptions’ heading.”
- Verification: “Do not invent product specs, pricing, or policy details. If unknown, say what you’d need to confirm.”
6) Constraints and must-not rules
Put your “hard boundaries” in plain language.
- “Do not include medical, legal, or financial advice.”
- “Do not claim integrations or features unless provided in the input.”
- “Do not quote competitors’ pricing.”
7) Output formats (make deliverables predictable)
Specify the exact structure you want for common outputs.
- “For blog posts: start with a 1–2 sentence intro, then H2 sections, then an FAQ.”
- “For emails: subject line options (3), then email body, then a short CTA.”
- “For code: include a brief explanation, then the code block, then usage steps.”
8) Examples (the fastest way to teach)
Examples reduce ambiguity. Include at least one “good” example and one “bad” example when the stakes are high (compliance, brand voice, regulated claims).
How to write strong Project Instructions (step-by-step)
Step 1: Start from the failures you want to prevent
List the top 5 ways Claude outputs go wrong in your project. Examples:
- It invents details you didn’t provide.
- It writes in the wrong voice (too salesy, too academic, too casual).
- It produces inconsistent formatting across deliverables.
- It skips clarifying questions and guesses.
- It ignores your preferred terminology.
Turn each failure into a rule (“If unknown, ask,” “Use these headings,” “Use these definitions”).
Step 2: Separate “always true” rules from “task-specific” prompts
Project Instructions should contain stable guidance. Keep the changing details (topic, product version, audience segment for this campaign) in the prompt you write for each task.
Practical test: If a line would change every week, it probably belongs in the task prompt, not the project instructions.
Step 3: Make rules measurable
Replace subjective language with observable requirements.
- Instead of “be concise,” use “keep intros under 60 words and paragraphs under 4 lines.”
- Instead of “use a friendly tone,” use “use direct sentences, avoid slang, and write in second person (‘you’).”
Step 4: Add an “unknowns and ambiguity” policy
This is one of the highest-leverage sections. It prevents confident-sounding guesses.
- “If the user asks for current pricing, availability, quotas, or UI steps, ask for the source or provide a general approach without specifics.”
- “If a claim would require verification, label it as a question or assumption.”
Step 5: Keep it short enough to maintain
Long instruction blocks can become stale. Aim for a set of rules you will actually update. If you need more detail, move it into a “reference” doc you paste only when relevant.
Claude Project Instructions examples (copy/paste)
Use these as starting points. Replace bracketed text with your project details.
Example 1: Content marketing + SEO (editorial, non-hype)
Claude Project Instructions (SEO Editorial)
- Role: You are an editorial writer and SEO editor for [brand].
- Audience: US readers; write in clear US English for an international audience.
- Voice: Practical, direct, non-hype. Avoid exaggerated claims and “game-changing” language.
- Accuracy: Do not invent prices, quotas, UI labels, benchmarks, or “according to” citations. If unknown, say what’s needed to confirm.
- Structure: Use descriptive headings. Each paragraph must add new information. Prefer steps, checklists, and examples.
- SEO: Use the primary keyword naturally in headings and early body text; avoid repetition.
- Output: Provide a scannable article with actionable steps and a short FAQ at the end.
- Clarify: If the request lacks product context, ask up to 5 clarifying questions before drafting.
Example 2: Customer support responses (consistent, policy-safe)
Claude Project Instructions (Support)
- Role: You are a customer support agent for [product].
- Goals: Resolve the issue, confirm understanding, provide next steps, and set expectations.
- Tone: Calm, respectful, and concise. No blame. No sarcasm.
- Policy: Do not promise timelines, refunds, or feature availability unless explicitly provided by the user’s internal notes.
- Process: Ask for missing details (device, OS, steps tried, error text). Summarize the issue back to the user.
- Output format: 1) Acknowledgement, 2) Clarifying questions (if needed), 3) Steps to try, 4) What to send us if it fails.
Example 3: Engineering design reviews (structured critique)
Claude Project Instructions (Design Review)
- Role: You are a senior engineer reviewing design proposals.
- Focus: Requirements coverage, tradeoffs, failure modes, security/privacy considerations, and operational complexity.
- Constraints: Do not assume infrastructure, vendors, or budgets not mentioned in the proposal.
- Output format:
- Summary (3 bullets)
- What’s strong
- Risks / gaps
- Questions to answer
- Suggested next iteration
- When uncertain: Ask clarifying questions instead of guessing.
Example 4: Brand voice guardrails (with good/bad examples)
Claude Project Instructions (Brand Voice)
- Voice: Confident, helpful, plain-spoken. Avoid buzzwords.
- Do: Use concrete verbs, short sentences, and specific examples.
- Don’t: Use hype (“revolutionary,” “unmatched”), vague claims, or pressure language.
- Good example: “Here’s how to export your data and what to check before you share it.”
- Bad example: “Unlock next-level productivity with our cutting-edge solution.”
Common mistakes (and how to fix them)
Mistake: Writing instructions as a marketing slogan
Fix: Replace slogans with rules Claude can follow: formatting, tone constraints, and what to do when information is missing.
Mistake: Mixing project rules with today’s task
Fix: Keep project rules stable. Put the specific deliverable request, inputs, and deadlines in the task prompt.
Mistake: Forgetting “what to do when you don’t know”
Fix: Add a short uncertainty policy: ask clarifying questions, list assumptions, and avoid invented specifics.
Mistake: Over-constraining outputs
Fix: Specify the output format and must-not rules, but allow flexibility in wording and ordering unless consistency is critical.
How to maintain Project Instructions over time
Project Instructions work best as a living document. When you see a recurring issue, add a rule or example. When a rule becomes irrelevant, remove it so it doesn’t conflict with new work.
- Keep a changelog note (optional): a one-line reason for each change (“Added rule to avoid pricing claims”).
- Review cadence: revisit after major launches, rebrands, or policy changes.
- Test with a standard task: run the same small request after edits to see if outputs improved.
Using CopyCharm to store and reuse Claude Project Instructions (and keep them consistent across tools)
If you write Project Instructions once and reuse them across many sessions, the friction is usually: finding the latest version, copying the right block, and keeping “stable rules” separate from “task prompts.” CopyCharm can help by acting as a Windows desktop workbench for copied text where you can save and retrieve the instruction blocks you reuse.
A concrete workflow: save, find, reuse
- Save: When you finalize a strong set of Claude Project Instructions, copy the full block and save it in CopyCharm as a Saved Prompt. Separately, you can favorite important reference clips you copy frequently (for example, a brand voice paragraph or a compliance disclaimer).
- Find: Later, when you start a new Claude project or need to re-apply your rules, open CopyCharm and search your past clips or saved prompts by a distinctive phrase (for example, “Uncertainty policy” or “Output format: Summary / Risks / Questions”).
- Reuse: Copy the saved instruction block from CopyCharm and paste it into Claude’s project instructions area (if available to you) or into the first message of a new project chat. For Claude and other apps (Gemini, Cursor, email, documents), this reuse is a manual copy/paste workflow.
When ChatGPT access matters (connector vs manual reuse)
If you also work in ChatGPT, CopyCharm offers an authenticated ChatGPT connector backed by optional AI Access sync. After an eligible user authorizes the account, enables and completes AI Access sync, and authorizes the connector, ChatGPT can search and retrieve only supported Synced Data (such as Favorite Clips and Saved Prompts, plus optional Other Clips if enabled). ChatGPT cannot access unsynced local CopyCharm data.
This is useful when you want ChatGPT to pull in your saved instruction block without you hunting for it manually. For Claude, the verified workflow remains: find it in CopyCharm, then copy/paste into Claude.
Try CopyCharm for saving and reusing instruction blocks
Frequently Asked Questions
FAQ 1: What should I put in Claude Project Instructions vs my normal prompt?
Answer: Put stable rules in Project Instructions (voice, definitions, constraints, formatting, how to handle unknowns). Put the changing request in your normal prompt (the specific deliverable, inputs, and context for today). If a line would change every time you run the task, it belongs in the task prompt.
Takeaway: Project Instructions are the “always true” rules; prompts are the “today” request.
FAQ 2: How long should Claude Project Instructions be?
Answer: Long enough to remove ambiguity, short enough to maintain. Start with role, audience, voice, constraints, and output format, then add only the rules that prevent repeated failures. If it becomes hard to keep current, split it into a core instruction block plus optional “reference” blocks you paste only when relevant.
Takeaway: Maintainability matters as much as completeness.
FAQ 3: How do I write Project Instructions that prevent hallucinated details?
Answer: Add an explicit accuracy policy: “Do not invent pricing, quotas, UI steps, or product capabilities. If missing, ask clarifying questions or list assumptions.” Also specify what to do when the user requests time-sensitive details: provide a general approach and ask for the authoritative source text to quote or summarize.
Takeaway: Tell Claude what to do when it cannot verify something.
FAQ 4: Should I include examples inside my Project Instructions?
Answer: Yes, when you need consistent style or strict boundaries. A short “good vs bad” pair can clarify tone, acceptable claims, and formatting faster than paragraphs of rules. Keep examples representative and update them when your brand voice or policies change.
Takeaway: Examples reduce interpretation errors.
FAQ 5: How do I handle multiple audiences or tones in one Claude project?
Answer: Define a default audience and tone, then add a simple switch rule: “If the user says ‘For developers,’ use the developer style; if ‘For executives,’ use the executive style.” Include a short checklist for each mode (reading level, length, and preferred structure). If the audiences are very different, consider separate projects or separate instruction blocks you paste as needed.
Takeaway: Use a default plus explicit mode switches to avoid mixed voice.
FAQ 6: What output-format rules work best for Claude Project Instructions?
Answer: The best rules are concrete and repeatable: required headings, bullet vs paragraph expectations, and where to put assumptions, risks, or next steps. If you want consistent deliverables, specify templates (for example: “Summary, Steps, Edge cases, FAQ”) and tell Claude to ask before deviating from the template.
Takeaway: Templates produce more predictable outputs than general style advice.
FAQ 7: How do I update Project Instructions without breaking consistency?
Answer: Change one thing at a time, then test with a standard task you run repeatedly. If you add a new constraint, also add a short example showing how it should look in output. Remove outdated rules so they don’t conflict with new ones, and keep definitions centralized so terminology stays consistent.
Takeaway: Small, tested edits keep instruction sets stable.
FAQ 8: Can CopyCharm help me reuse Claude Project Instructions across projects and tools?
Answer: Yes. CopyCharm is a Windows desktop app that saves copied text locally, lets you search past clips, favorite important clips, and separately save reusable prompts. You can store your Claude Project Instructions as a Saved Prompt, quickly find it later via search, and copy/paste it into Claude (and other apps). If you also use ChatGPT, CopyCharm has an authenticated connector backed by optional AI Access sync; after authorization and sync, ChatGPT can search and retrieve supported synced data, but it cannot access unsynced local CopyCharm data.
Takeaway: Keep one maintained instruction block and reuse it consistently, with manual paste into Claude.