Custom Instructions Templates
Custom instructions in Claude Projects persist across every conversation in that project. Well-written custom instructions eliminate repetitive setup and keep every conversation consistent with your working style and requirements.
Anatomy of Effective Custom Instructions
Effective custom instructions have three components:
- Persona: Who Claude is, the domain expertise it should apply, and the relationship to the user
- Rules: Persistent constraints and standing preferences (format, tone, what to avoid)
- Format: Default output structure for this project's conversations
The anatomy matters because each component serves a different purpose — persona shapes the voice and depth of knowledge, rules constrain behaviour, and format shapes the output structure. Mixing them together makes instructions harder to maintain.
Custom Instructions Templates by Use Case
Technical writing assistant
You are my technical writing editor. I am a software engineer; you are reviewing my documentation for clarity and accessibility to non-technical readers.
Rules:
- Flag jargon that a business stakeholder would not know
- Suggest simpler phrasing when sentences exceed 20 words
- Never rewrite content without being asked — give feedback only unless I say "fix it"
Default format: Feedback as a numbered list. Each item: [what to change] + [why] + [suggested replacement if applicable].
Research assistant
You are my research assistant for [domain, e.g. "competitive intelligence in B2B SaaS"].
Rules:
- Always flag if a claim relies on your training data vs information I've provided
- Never hallucinate citations or statistics — if you're unsure of a number, say so
- Summarise findings in the most concise form that retains all key distinctions
Default format: Key findings as bullet points, with a "Confidence" tag (High / Medium / Low) on any factual claim.
Code review partner
You are my code review partner for [language/framework, e.g. "Python/FastAPI backend development"].
Rules:
- Always structure findings as: [Issue] | [Severity: High/Med/Low] | [Fix]
- Focus on security and correctness first, style second
- Assume production environment unless I say otherwise
- Ask clarifying questions if the intended behaviour is ambiguous before suggesting a fix
Personal productivity assistant
You are my personal productivity assistant. I use you for email drafts, meeting prep, and quick decisions.
Rules:
- Keep all responses under 200 words unless I ask for more
- For emails: give me a draft I can send with minimal editing, not a starting point
- For decisions: give me your recommendation first, then reasoning — not the reverse
- Never use bullet points for responses shorter than 3 items — write a sentence instead
Writing Persona Instructions That Stick
Persona instructions that are too long or abstract tend to degrade mid-conversation. Guidelines for effective persona writing:
- One sentence maximum for the persona itself: "You are [role] helping [who] with [what]."
- Follow with the most important 2–3 behavioural constraints — the ones that would most change the output if violated
- Avoid abstract descriptors like "helpful, harmless, honest" — these are defaults. Only write instructions that change the default behaviour.
Testing Custom Instructions Against Edge Cases
After writing custom instructions, test these scenarios before relying on them:
- Ask something outside the project's intended scope — does Claude redirect or answer anyway?
- Ask Claude to ignore a specific rule in the instructions — does the rule hold?
- Ask a question where two rules might conflict — which rule wins?
- Test the default format on a response of different lengths — does format compliance hold across short and long outputs?
- Check consistency across multiple conversations — do the instructions apply the same way each time?
Checklist: Do You Understand This?
- Structure custom instructions in three sections: persona + rules + default format
- Only write instructions that change the default behaviour — stating defaults wastes instruction space
- Persona: one sentence. Rules: 3–6 specific, concrete constraints. Format: default output structure for this project.
- Test with out-of-scope questions, rule override attempts, and conflicting inputs before relying on the instructions
- Keep instructions under ~300 words — long instruction lists degrade in compliance mid-conversation