Claude Custom Instructions: The Complete Guide to Making Claude Work Your Way

Claude is brilliant out of the box. But without custom instructions, you are leaving most of its power on the table. This is the best guide to Claude custom instructions — updated for 2026 with templates, best practices, and the exact framework we use to make Claude work exactly the way we need it to.

Custom instructions tell Claude who you are, how you work, and what you expect — before you even ask a question. They are the difference between getting a generic AI response and getting exactly what you need, every time.

We use Claude with custom instructions for everything at Like One — writing code, drafting emails, analyzing data, managing our nonprofit. This guide is what we have learned after thousands of conversations.

What Custom Instructions Actually Are

Custom instructions are persistent context you give Claude that applies to every message in a conversation. Instead of repeating "write in a casual tone" or "I am a software engineer" every time, you tell Claude once and it remembers for the entire session.

Think of them as a briefing document. Before a new employee starts, you hand them a document explaining how your team works — communication norms, technical standards, things to avoid. Custom instructions serve the same purpose for Claude.

There are three places you can set them:

• Claude.ai Profile Settings — Global instructions that apply to every new conversation. Set these once and forget them.
• Claude Projects — Project-specific instructions plus uploaded documents. Perfect for work contexts where you need Claude to know your codebase, brand guidelines, or team processes.
• CLAUDE.md Files — For Claude Code (the CLI tool), instructions live in a file in your repository. Claude reads them automatically on every session.

Each layer builds on the last. Your global profile sets baseline behavior. Projects add specialized context. CLAUDE.md files make Claude an expert on your specific codebase.

Before and After: What Custom Instructions Actually Change

The difference between Claude with and without instructions is not subtle. Here is a real example.

Without Custom Instructions

You ask: "How should I handle this API error?"

Claude responds with a generic explanation of try-catch blocks, mentions five different programming languages, suggests three different error handling philosophies, and adds disclaimers about production readiness. You get 800 words when you needed 50.

With Custom Instructions

Same question. But your instructions say: "I work in TypeScript with Express. Be concise. Show code, not explanations. Use our error middleware pattern."

Claude responds with a 10-line TypeScript snippet that plugs directly into your existing middleware chain. No preamble. No alternatives you did not ask for. Just the answer, in your stack, matching your patterns.

That is not a hypothetical. That is Tuesday for anyone who has taken ten minutes to write proper instructions.

The Framework: What Good Custom Instructions Include

Bad custom instructions are vague wishlists. Good ones are specific operating manuals. Here is the framework we use:

1. Identity Context

Tell Claude who you are, what you do, and what matters to you. This is not vanity — it is calibration.

I am a frontend developer at a Series B startup. 
We use React, TypeScript, and Tailwind. 
Our users are enterprise procurement teams. 
I care about accessibility and clean component APIs.

Now every code suggestion, every explanation, every recommendation is filtered through your actual context. Claude will not suggest jQuery or Bootstrap when it knows your stack.

2. Communication Preferences

Tell Claude how you want information delivered. Be specific about format, length, and tone.

- Be concise. Lead with the answer, then explain if needed.
- Use code examples instead of describing what code should do.
- Skip disclaimers and caveats unless I ask for risks.
- When I share code, read it carefully before suggesting changes.
- Never apologize for mistakes. Just correct them.

Most people skip this step and then complain that Claude is "too verbose" or "too cautious." The model is not the problem. Your instructions are.

3. Output Format Rules

If you always want bullet points, say so. If you hate markdown tables, say so. If your team uses a specific documentation format, include a template.

Format all technical explanations as:
1. One-sentence summary
2. How it works (3-5 sentences max)
3. Code example
4. Common pitfalls

This eliminates the "reformatting loop" where you spend three messages getting Claude to restructure its answer the way you wanted from the start.

4. Domain Knowledge

Give Claude the facts it cannot infer. Company terminology, internal tool names, team conventions, regulatory requirements — anything that makes your context unique.

Our API uses snake_case for all endpoints.
"Workspace" means a customer organization (not a dev environment).
All user-facing text must pass WCAG 2.1 AA.
We deploy via GitHub Actions to AWS ECS.

5. Boundaries and Guardrails

Tell Claude what NOT to do. Negative instructions are often more useful than positive ones because they prevent the specific failure modes you have already encountered.

- Never suggest adding comments to obvious code.
- Do not refactor code I did not ask you to change.
- Do not add error handling for impossible states.
- Do not suggest switching to a different framework.

Templates You Can Use Right Now

For Software Engineers

You are my pair programming partner.
Stack: [your stack]. Style: [your conventions].
Rules:
- Read my code before suggesting changes.
- Prefer editing existing code over creating new files.
- Match the style of the surrounding code.
- Only add types when they add clarity, not bureaucracy.
- Test suggestions should use [your test framework].
- When I share an error, diagnose the root cause first.

For Writers and Content Creators

You are my writing partner, not my ghostwriter.
My voice: [casual/technical/academic]. My audience: [who].
Rules:
- Suggest improvements, do not rewrite unless I ask.
- Flag weak arguments instead of polishing bad ideas.
- No filler phrases ("It is worth noting", "In today's world").
- Keep paragraphs under 4 sentences.
- When I share a draft, start with what works before suggesting fixes.

For Business and Strategy

You are my strategic advisor. I run a [type] business.
Revenue: [range]. Team: [size]. Industry: [sector].
Rules:
- Ground recommendations in our actual constraints.
- Quantify when possible, qualify when you cannot.
- Challenge my assumptions when you see blind spots.
- Separate "nice to have" from "must do" explicitly.
- No generic advice. Every suggestion should reference our specifics.

For Students and Researchers

You are my research assistant and study partner.
Field: [your discipline]. Level: [undergrad/grad/PhD].
Rules:
- Cite sources when making factual claims.
- Distinguish between established consensus and active debate.
- When I share my writing, focus on argument structure first.
- Explain complex concepts using analogies from [familiar domain].
- Challenge weak reasoning. Do not just validate my ideas.

For Freelancers and Consultants

You are my business operations partner.
I freelance in [field]. Clients are [type]. Rate: [range].
Rules:
- Draft client communications in a professional but warm tone.
- When scoping projects, always flag potential scope creep.
- Help me say no to bad-fit clients diplomatically.
- Track deliverables and deadlines when I share project details.
- Proposals should emphasize outcomes, not hours.

Claude Projects: Custom Instructions on Steroids

Claude Projects take custom instructions to another level by combining them with uploaded documents. A project gives Claude a persistent workspace with:

• Custom instructions specific to that context
• Up to 200K tokens of reference documents
• Conversation history that builds on itself

The killer use case is giving Claude your actual documentation. Upload your API specs, style guide, and architecture decisions. Now when you ask Claude to write a new endpoint, it follows your actual patterns — not generic best practices from its training data.

We run separate projects for code review, blog writing, grant applications, and legal research. Each one has its own instructions and reference documents. The context switch between tasks takes zero effort because the project handles it.

Project Instruction Tips

• Be specific about the project scope. "This project is for writing API documentation for our payments service" beats "This is for work stuff."
• Include examples of good output. Show Claude a completed document, email, or code review that represents your quality bar.
• Reference your uploads explicitly. Say "Follow the patterns in api-specs.md" so Claude knows which document to prioritize.
• Update instructions as you learn. When Claude makes a recurring mistake, add a guardrail. Your instructions should evolve with your usage.
• Separate concerns across projects. A project for code review and a project for marketing copy should not share instructions. Different contexts need different Claude behaviors.

What to Upload to Claude Projects

Not all documents are equally useful. Here is what actually improves Claude's output when uploaded to a project:

• Style guides and brand voice documents — Claude will match your tone precisely.
• API documentation and schemas — Generates code that works with your actual endpoints.
• Architecture decision records (ADRs) — Claude understands WHY you made certain choices.
• Example outputs you love — The single most effective thing you can upload. Claude pattern-matches beautifully.
• Glossaries and terminology lists — Eliminates the "that is not what we call it" problem.

CLAUDE.md: Custom Instructions for Claude Code

If you use Claude Code (Anthropic's CLI for coding), custom instructions live in a CLAUDE.md file at the root of your repository. Claude reads this file automatically at the start of every session.

This is where custom instructions become genuinely powerful. Your CLAUDE.md can include:

• Build and test commands
• Architecture decisions and their rationale
• File organization conventions
• Code style rules that linters do not catch
• Deployment processes and safety checks

Our CLAUDE.md is over 100 lines. It tells Claude our stack, our naming conventions, which directories to never modify, how to run tests, and what quality standards we expect. The result is that Claude Code produces pull-request-ready code on the first attempt — because it knows our standards before writing a single line.

CLAUDE.md Structure That Works

After maintaining our CLAUDE.md across hundreds of coding sessions, here is the structure that produces the best results:

# Project Overview
One paragraph: what this project is, who it serves.

# Tech Stack
List every framework, language, and major dependency.
Include versions when they matter.

# Commands
- Build: `npm run build`
- Test: `npm run test`  
- Lint: `npm run lint`
- Deploy: `./scripts/deploy.sh`

# Architecture
- /src/api — Express routes, one file per resource
- /src/services — Business logic, no HTTP awareness
- /src/models — Database schemas and queries
- /src/utils — Pure functions only

# Conventions
- All API responses use { data, error, meta } shape
- Use early returns over nested conditionals
- Services throw typed errors, routes catch and format
- Tests co-locate with source: foo.ts → foo.test.ts

# Do Not
- Never modify /src/generated — these are auto-generated
- Never add dependencies without noting in DECISIONS.md
- Never use any/unknown without a comment explaining why

The key insight: CLAUDE.md works best when it mirrors how you would onboard a senior developer. Tell them the things that are not obvious from reading the code alone.

CLAUDE.md vs Project Instructions: When to Use Which

Use CLAUDE.md when you are writing code with Claude Code in a terminal. Use Claude Projects when you are in the web interface working with documents, strategy, or anything non-code. They serve different workflows:

• CLAUDE.md — Lives in version control. Team-shared. Code-focused. Evolves with your codebase.
• Projects — Personal or team workspaces. Document-heavy. Good for writing, analysis, research.

If your team uses Claude Code, your CLAUDE.md becomes part of your repository — every developer benefits from it, and it evolves through pull requests like any other documentation.

Character Limits and Token Budgets

Every instruction type has a practical limit. Going over does not crash anything — it just means later instructions get less attention as the context window fills up. Here are the current limits as of 2026:

• Claude.ai Profile Instructions — 1,500 characters. Enough for your core identity, communication style, and 5-8 key rules. This is your most constrained space, so make every word count.
• Claude Projects Custom Instructions — approximately 8,000 characters (roughly 2,000 words). Plus up to 200K tokens of uploaded documents. Projects give you far more room for domain-specific context.
• CLAUDE.md for Claude Code — no hard character limit, but practical sweet spot is 1,000-2,500 words. Claude reads the entire file on session start, so longer files consume context you might need for code.
• API System Prompts — limited only by your model's context window (200K tokens for Claude Opus, 200K for Sonnet). In practice, keep system prompts under 4,000 tokens for best instruction adherence.

The golden rule: shorter instructions followed more reliably than longer ones. If you need more than 1,000 words of instructions, consider splitting across profile (baseline behavior) and project (domain-specific) layers.

Best Practices for Claude Custom Instructions in 2026

After running thousands of Claude conversations with custom instructions, these are the best practices that consistently produce superior results:

• Start with constraints, not capabilities. Telling Claude what NOT to do is more effective than describing ideal behavior. Claude already tries to be helpful — your job is to remove the behaviors you dislike.
• Use imperative language. "Be concise" works better than "I would prefer if you could try to be more concise." Direct commands get direct compliance.
• Layer your instructions. Profile for identity and tone. Projects for domain knowledge. CLAUDE.md for code conventions. Each layer serves a different purpose — do not dump everything into one place.
• Include examples of good output. One example is worth ten rules. Show Claude what a perfect response looks like for your most common request type.
• Test and iterate. After writing instructions, run your five most common prompts and evaluate. Adjust based on what Claude gets wrong, not what you think it might get wrong.
• Version control your instructions. Keep a copy in your notes app or repository. When you update, you can compare what changed and roll back if new instructions make things worse.
• Match instruction depth to task complexity. Simple tasks need simple instructions. Overloading Claude with rules for straightforward conversations adds noise without value.

The best custom instructions for Claude are not the longest — they are the most specific to your actual workflow. Five precise rules beat fifty vague suggestions every time.

The Five Mistakes That Waste Your Instructions

1. Being Too Vague

"Be helpful and accurate" tells Claude nothing. It is already trying to be helpful and accurate. Useful instructions are specific enough that they change Claude's default behavior.

Bad: "Write good code."
Good: "Use TypeScript strict mode. Prefer composition over inheritance. Every function under 20 lines."

2. Writing a Novel

Custom instructions have token limits. Do not waste them on backstory or philosophy. Every line should directly affect Claude's output. If removing a line would not change anything, remove it.

Test: Read each instruction line and ask "what would Claude do differently without this?" If the answer is "nothing," delete it.

3. Contradicting Yourself

"Be concise" followed by "always explain your reasoning in detail" creates confusion. Claude will try to satisfy both and satisfy neither. Prioritize your instructions and resolve conflicts before saving them.

Fix: Add context to resolve ambiguity. "Be concise for code suggestions. Explain reasoning in detail only when I ask why."

4. Never Updating

Your first set of custom instructions will not be perfect. Treat them like code — iterate based on what works and what does not. When Claude produces output you do not like, ask yourself: "Could better instructions have prevented this?"

Practice: Review your instructions every two weeks. Remove what is not working. Add rules for repeated annoyances.

5. Ignoring Context Windows

Custom instructions consume tokens from your context window. A 2,000-word instruction set might seem thorough, but it reduces the space available for your actual conversation. Keep instructions tight — every word should earn its place.

Rule of thumb: Profile instructions under 500 words. Project instructions under 1,500 words. CLAUDE.md under 2,000 words. Go longer only when the specificity demonstrably improves output.

Troubleshooting: When Custom Instructions Are Not Working

Sometimes you write instructions and Claude seems to ignore them. Here is what is usually happening and how to fix it.

Claude keeps reverting to default behavior

Your instructions might be too buried or too subtle. Claude weighs explicit, direct statements more heavily than suggestions. Change "try to be concise" to "maximum 3 sentences per response unless I ask for more detail."

Claude follows some instructions but ignores others

Check for contradictions. If instruction 3 conflicts with instruction 7, Claude will follow whichever seems more relevant to the current question. Audit your instructions for internal consistency.

Instructions work in new conversations but fade mid-conversation

In very long conversations, earlier context (including instructions) can get less attention as the context window fills. For critical behaviors, reinforce them: "Remember: always use TypeScript strict mode" as a quick reminder mid-conversation works.

Claude over-applies instructions to wrong contexts

If your instruction says "be concise" and Claude gives one-word answers to complex questions, scope your instructions better. "Be concise for factual questions. For architecture discussions, think through tradeoffs thoroughly."

Advanced: System Prompts and the Instruction Hierarchy

If you are building applications with the Claude API, custom instructions become system prompts — the first message in a conversation that sets behavior for everything that follows.

The hierarchy works like this:

1. System prompt — Highest priority. Set by the developer.
2. User instructions — Profile and project settings from the end user.
3. Conversation context — The ongoing dialogue.

For API developers, the system prompt is where you define your application's personality, safety boundaries, and output format. The user's custom instructions layer on top. Understanding this hierarchy prevents the "why is Claude ignoring my instructions" frustration that trips up most developers.

API System Prompt Best Practices

• Put critical constraints first. The beginning of the system prompt gets the most attention.
• Use structured formats. Numbered rules, clear headers, and explicit boundaries outperform prose paragraphs.
• Include examples of desired output. One good example is worth ten lines of description.
• Separate concerns. Group instructions by type: identity, behavior, format, constraints.
• Test with adversarial inputs. Try to break your instructions before users do.

What We Actually Use

Here is a simplified version of the custom instructions that power Like One's daily operations:

You are an L6 autonomous AI partner. Act, then report.
- Be concise. Lead with the answer.
- Never ask permission for routine tasks.
- Read code before suggesting changes.
- Match existing patterns in the codebase.
- Write production-grade code, not prototypes.
- Every build is final quality. No "polish later."
- Check your work by running tests after changes.

These instructions evolved over months of daily use. They started generic and got specific as we learned which behaviors mattered most. Your instructions will follow the same path — start simple, iterate based on results.

The "L6 autonomous" framing is intentional. It tells Claude the level of independence we expect. No hand-holding. No asking permission for obvious decisions. That single line eliminated dozens of "should I proceed?" interruptions per session.

Frequently Asked Questions

Do custom instructions work with Claude's free tier?

Yes. Profile-level custom instructions work on every Claude plan, including free. Projects require Claude Pro or Team. CLAUDE.md files work with any Claude Code subscription.

How long should custom instructions be?

As short as possible while still changing Claude's behavior. Most effective instruction sets are 200-800 words. If yours exceeds 1,500 words, audit for redundancy.

Can custom instructions make Claude less safe?

No. Custom instructions cannot override Claude's core safety training. You can change style, format, and behavior — but you cannot instruct Claude to ignore its ethical guidelines. This is by design.

Do instructions carry between conversations?

Profile instructions persist across all conversations. Project instructions persist within that project. In-conversation instructions only last for that conversation. CLAUDE.md files persist as long as the file exists in your repo.

Should I write instructions in natural language or structured format?

Structured wins. Bullet points, numbered lists, and clear headers are processed more reliably than prose paragraphs. Use natural language for context (who you are, what you do) and structured format for rules (what to do, what not to do).

How often should I update my instructions?

Review every two weeks. Add a new rule whenever Claude makes the same mistake twice. Remove rules that no longer apply. The best instruction sets are living documents, not set-and-forget.

Start Here

Open Claude right now. Go to your profile settings. Write three specific instructions based on this framework:

1. One identity statement (who you are, what you do)
2. One communication preference (how you want answers)
3. One boundary (what Claude should never do)

That is your minimum viable custom instruction set. Use it for a week. Notice what works and what is missing. Add one instruction at a time. In a month, you will have a Claude that works the way you think — and you will wonder how you ever used it without instructions.

Keep Reading

• What Are Agentic Loops? The Complete Explanation — Custom instructions are even more powerful inside agentic loops, where Claude executes multi-step tasks autonomously.
• Claude Code: The Complete Guide to AI-Powered Software Development in 2026
• How to Build a Personal AI Assistant That Actually Remembers You
• How to Give Your AI Agent Persistent Memory That Actually Works
• How to Use Claude Projects: The Complete Guide

Wondering which Claude model pairs best with custom instructions? Check our Claude Sonnet vs Opus comparison to pick the right model for your workflow.