If you have written custom instructions for a Gemini Gem and felt the result drift from what you actually wanted, you are not alone. I run about five Gems for daily work, and the early ones never quite did what I expected. After a lot of iteration I found that the patterns differ a bit from what works for ChatGPT's Custom GPTs.
This article walks through the structure I now use for custom instructions and the missteps I made along the way. Google's official guidance covers some of this, but a few rules emerge clearly only when you actually compare runs.
Write instructions in three layers: role, constraints, format
The single biggest improvement in my Gems came from organizing the instruction into three layers.
Layer 1: role (who you are) Layer 2: constraints (what you must / must not do) Layer 3: output format (how to respond)
Concretely, here is the structure of a Gem I use for cleaning up meeting transcripts.
# Role
You are an assistant that turns raw meeting transcripts into structured summaries.
The user pastes a transcript; you organize it into the format below.
# Constraints
- No speculation or invention. Only include statements actually made.
- Replace personal names with role titles (e.g., Marketing Lead).
- If you see signals of confidentiality (NDA, unreleased, internal-only), prepend ⚠️.
- Always respond in English.
# Output format
## Meeting Overview (max 2 sentences)
## Decisions (3-5 bullets)
## Action Items (with owner and deadline)
## Open questions for next time (if any)
Splitting like this lets the Gem reliably reproduce "understand role, honor constraints, hit the format." It is noticeably better than the same content written as one long paragraph.
Prefer positive framing over negation
If you stack only "do not" instructions, Gemini tends to drop some of them. Lead with the positive form, supplement with a short negative when needed.
Less effective: "Do not break formal tone. No casual speech." Better: "Maintain a professional tone in every response."
When several negations sit side by side, the model forgets one of them. Anchoring the rule positively keeps it intact.
A couple of few-shot examples make a real difference
Some posts say custom instructions should not include examples. My experience says the opposite. One or two few-shot examples reliably lift response quality.
Continuing the meeting Gem:
# Example
Input: "Starting next week we are bumping the new build to top priority. Tanaka-san owns it, deadline 10/15."
Output:
## Meeting Overview
The team agreed to elevate the new build to top priority.
## Decisions
- New build elevated to highest priority
## Action Items
- Engineering Lead: complete initial implementation by 10/15
With examples, format interpretation stops drifting. More than three and the instruction gets too long; one or two is the sweet spot.
Tell it not to volunteer unrequested information
Gemini is helpful by default, which can mean adding extra context the user did not ask for. In productivity Gems this becomes noise.
A constraint along these lines helps a lot:
- Do not return information the user did not ask for.
- No "for reference" or "by the way" appendices.
- If clarification is needed, ask one question at the end of your response, not before the answer.
The chatty preface and unnecessary asides drop dramatically.
Make knowledge file precedence explicit
Gems can carry uploaded knowledge files (docs, PDFs). Without explicit direction, the Gem treats them as merely "for reference" and may answer from training data instead.
A clause like this puts knowledge files first.
# Knowledge file policy
- The attached knowledge files are authoritative. Internal knowledge that contradicts them is overruled.
- If you must respond with information not in the knowledge files, say so explicitly.
- When citing, name the section or chapter you drew from.
Critical for internal knowledge bots and product FAQ Gems. Without it, the Gem will sometimes argue against the user's "but our latest internal rule says X" because its training cutoff says otherwise.
Be specific about tone
Tone instructions are fuzzy by default. "Friendly" or "professional" alone leaves Gemini too much room.
Concrete tone control looks like:
# Tone
- Sentence length: average 20-40 words; avoid long sentences
- Second person: use "you" directly; avoid "everyone" / "our customers"
- Emojis: do not use
- Casualness: as if explaining to a knowledgeable colleague; not slang
- Jargon: explain on first use in one sentence
Numbers and explicit examples narrow the variance.
Trip-up #1: long instructions get partially ignored
I once over-engineered an instruction set, and the Gem started honoring maybe half of it.
Empirically, instructions stay reliable around 800-1500 characters (or roughly 200-400 words in English). Past that, the Gem starts forgetting middle items.
If yours is overflowing, options are: drop low-priority rules, replace prose with a few-shot example, or move content into a knowledge file.
Trip-up #2: "absolutely never" is not magic
This applies to LLMs broadly: emphatic "absolutely never" or "under no circumstances" sometimes works and sometimes does not. Specific forbidden examples consistently outperform emphatic phrasing in my testing.
Less effective: "Absolutely never expose personal names." Better: "If a personal name appears (e.g., Tanaka, Sato), substitute the role title."
Concrete cases give the Gem something to anchor the rule on.
Trip-up #3: no version history
Gems do not currently let you roll back to a previous version. Edits overwrite.
I keep masters in external Markdown files instead.
gems/
meeting-summary/
instructions.md # master
knowledge/
style-guide.pdf
glossary.md
changelog.md # manual change log
The Gem holds a copy; the master lives locally. When "last week's version was working, can I get it back" comes up, you can.
One thing to try tomorrow
If your Gem's behavior is mildly off in a way you cannot pin down, rewrite the instructions into the three-layer structure (role / constraints / format). That alone will visibly stabilize responses.
From there, add one few-shot example and a "no unrequested information" constraint. Three or four edits and you usually arrive at a Gem that does what you intended.
Custom Instructions Are a Living Specification
Gem custom instructions are effectively the system prompt for your custom assistant. The trick is treating them like a spec you keep editing, not a document you write once and file away. Write the rough first draft. Use the Gem for a week. Come back and rewrite whatever underperformed. That loop beats trying to get it right upfront.
The Five-Section Template
Every Gem I build looks like this:
1. ROLE — who the Gem is (profession, stance, expertise)
2. GOAL — what the user is trying to achieve with it
3. INPUT — what the user will provide, and how to receive it
4. OUTPUT — shape, tone, level of detail
5. CONSTRAINTS — what not to do
The CONSTRAINTS section is the one most people skip. Don't. Adding it reduces off-the-rails answers more than any other single change.
ROLE
You are a professional editor of Japanese technical articles, with 10+ years of experience in IT/AI content.
GOAL
Improve the user's draft along three axes:
- Typo and grammar fixes
- Tone consistency (polite "desu/masu" form throughout)
- Conciseness ("X できます" → "X できます" etc.)
INPUT
The user pastes an article in Markdown or plain text. Text inside code blocks is not subject to editing.
OUTPUT
- The edited full text, preserving Markdown formatting
- A trailing bullet list of the five most important changes
- No large rewrites — respect the author's voice
CONSTRAINTS
- Do not switch to plain form ("da/de aru")
- Do not add marketing words like "revolutionary" or "groundbreaking"
- Do not add closing flourishes like "How was that?"
Those CONSTRAINTS matter. LLMs default to adding a cheerful closing summary. Explicitly forbidding the closer keeps the Gem feeling like a craftsperson editor rather than a content-farm template.
### Always Build a Test Set
Once the Gem works, save three to five representative inputs alongside the instructions — both successes and failures. Whenever you edit the instructions, rerun the saved inputs. You'll catch regressions that would otherwise show up as a slow drift in quality.
## Three Failure Modes to Avoid
**Vague instructions.** "Be thoughtful" and "be clear" do basically nothing. Replace with measurable versions: "in three sentences or fewer," "prose not bullets."
**All negatives, no positives.** Stacking prohibitions without any positive expectations leaves the model unsure what to do in their place. Balance "don't" with "do."
**No saved test set.** Build the Gem, use it, assume it's fine, and watch quality drift. Save representative inputs from day one and rerun them whenever you edit.
## What to Do Next
Good Gems compound across a team. A code review Gem, a release notes drafter, a brand voice editor — once three or four live in a shared library, knowledge reuse gets real.
For deeper control beyond Gems, see our Gemini 2.5 Pro production guide on the API side.