Learn Prompting in Practice: From Good to Great Custom Instructions and Persistent Prompts

Custom Instructions and Persistent Prompts

Intermediate 🕐 12 min Lesson 3 of 14
What you'll learn
  • Configure ChatGPT Custom Instructions using constraint-style writing in the response behavior box rather than description-style in the bio box
  • Set up a Claude Project with a persistent instruction block and understand how the knowledge base extends its capabilities
  • Apply the persistent vs. per-session decision framework to sort your standing preferences and task-specific requirements correctly

You're Re-Explaining Yourself Every Session. There's a Fix.

Every time you open a new AI conversation, you start from zero. The model does not know your role, your preferences, your tone requirements, or your standing rules. So you either re-explain all of it (inefficient), skip the context (and get generic output), or paste in a boilerplate header you've kept in a notes doc (better, but fragile). All three approaches treat persistent context as an afterthought.

All three major AI platforms — ChatGPT, Claude, and Gemini — have built persistent instruction systems specifically to solve this problem. Using them well is one of the highest-leverage things an intermediate user can do. The payoff is cumulative: every conversation starts with the right context already in place.

ChatGPT Custom Instructions: Two Boxes, One Strategy

ChatGPT's custom instructions system presents two text boxes. The first asks what you want ChatGPT to know about you. The second asks how you want it to respond. As of mid-2026, Plus users can fill up to 5,000 characters across both boxes.

The most common mistake is filling box one with a general biography: "I'm a marketing professional with 10 years of experience." This is almost entirely wasted. The box that matters most is box two — the response behavior box. The key insight from practitioners: write constraints, not descriptions.

Weak (description-style): "I prefer concise responses that are easy to read."

Strong (constraint-style): "Default response length: under 200 words. Never use bullet points unless I ask for a list. If you're uncertain whether I want more depth, ask — don't pad."

Constraints are executable. Descriptions are suggestions the model interprets loosely. A well-written custom instructions box removes ambiguity about what "good output" looks like for you specifically.

Claude Projects: The Persistent Workspace

Claude Projects are more than a custom instruction box — they are persistent workspaces. Each project has a custom instruction field (the system prompt that applies to every conversation in that project) and a knowledge base where you can upload documents, style guides, brand voice references, or reference material that Claude will draw on automatically.

Projects shine for recurring work types: a copywriting project with your brand voice and style guide uploaded, a research project with your domain reference documents, a coding project with your architecture decisions and naming conventions. The knowledge base means Claude does not just know your preferences — it knows the material you work with regularly.

Best practice for Claude Project instructions: keep them short and directive. "Use TypeScript strict mode" works better than a paragraph explaining your team's history with TypeScript. Claude attends carefully to explicit instructions — you don't need to justify them, just state them clearly.

Gemini Gems: The Bundled Expert

Gemini Gems (available on Gemini Advanced plans) take a different architectural approach: you build a named, purpose-specific AI expert that bundles a name, instructions, and optional connected knowledge from Google Drive into a reusable configuration. Each Gem is a single-purpose persona rather than a general-purpose assistant with preferences attached.

The practical difference: instead of one set of custom instructions that applies to everything, you build multiple Gems — one for writing, one for research, one for data analysis — and open the appropriate one for the task. Gemini's massive context window (1 million tokens) means Gems can work with entire document libraries pulled live from Drive, not static file uploads.

What Belongs in Persistent Instructions

Not everything should live in persistent settings. These elements earn their place in custom instructions or project prompts:

  • Standing response format rules (length, structure, tone, what to avoid)
  • Your role and relevant context that applies to most of your work
  • Recurring constraints (never suggest X, always cite sources, default to metric units)
  • Audience awareness (who you usually write for)

These elements belong in per-session prompts, not persistent settings:

  • Task-specific requirements that change from session to session
  • Context specific to one deliverable
  • Constraints that would conflict with other work you do

The Maintenance Rule

Persistent instructions go stale. Your role changes, your preferences evolve, your projects shift. Build a habit of reviewing your custom instructions quarterly — or immediately when you notice that the defaults are producing the wrong kind of output. A five-minute review every few months compounds significantly over time because every interaction benefits from the update.

The other maintenance consideration: if a particular constraint is producing good results in a specific context but would be wrong for others, move it out of persistent settings and into a per-session template. Persistent settings should contain only what is true across all or most of your work.

Key takeaways
  • Custom instructions work best when written as constraints (executable rules) rather than descriptions (style suggestions the model interprets loosely)
  • Claude Projects add a knowledge base layer — uploaded documents become persistent reference material available in every conversation within that project
  • Gemini Gems are single-purpose personas, not general preference containers — build one per work type rather than one with everything in it
  • Persistent instructions should contain only what is true across most of your work; task-specific requirements belong in per-session prompts, not global settings
  • The quarterly maintenance rule applies to all platforms — persistent instructions written months ago may conflict with how you work today, and stale context produces consistently off-target output until you update it