Gemini Gems Not Following Instructions: Find the Conflict

When a Gemini Gem stops following your instructions, there is almost always a conflict in the setup: the Gem is following one instruction while breaking another, or it has no clear example of what the right output looks like. Fixing it means finding that conflict, not rewriting everything from scratch.

Gems are custom AI configurations in Google's Gemini, built with a set of instructions that tell the assistant how to behave. When those instructions are incomplete, vague or pull in different directions, the model has to guess. It usually guesses wrong in a consistent and diagnosable way. Tools like fenbs help teams keep the reviewed, working version of a prompt alongside the decisions behind each rule, so the next test starts from a known-good baseline.

Check for competing instructions

Read your Gem instructions top to bottom and look for rules that contradict each other. A common pair: "be concise" and "include all relevant background." Another: "always ask a clarifying question" and "keep replies to one paragraph." The model cannot satisfy both at once, so it picks one based on proximity or training and ignores the other.

Write each rule on its own line. Then ask yourself: can the model follow rule 2 while following rule 1? If not, one of them needs to give way. When you have a rule that applies in most cases but has exceptions, state the exception explicitly rather than leaving the model to infer it.

Make requirements specific

Instructions like "write professionally" or "sound helpful" give the model almost no information. Professional can mean formal legal prose or friendly customer-service copy. Helpful can mean adding caveats or stripping them out. Replace adjectives with observable behaviors: "use short sentences," "start each reply with the direct answer before the explanation," or "never use bullet points."

If you have a specific format you want, describe the structure of the output. Say how many sections it should have, what each section should contain, and what order they come in. A model that knows the exact shape of a good reply is far less likely to produce a different shape.

Add a worked example

For most Gem failures, adding one good input-output example solves more than rewriting the rules. An example tells the model concretely what "following the instructions" looks like. Describe a realistic input, then show the ideal output in full.

Keep the example realistic. If your Gem handles support questions, use a real support question as the sample input. If your Gem writes summaries, show a real document and a real summary. An abstract example ("User asks about topic X, assistant replies clearly") adds very little because "clearly" is still undefined.

You can also add a counter-example: here is an input that looks similar but should be handled differently. Counter-examples are useful when the model keeps conflating two cases it ought to treat separately.

Check for unsupported expectations

Some instructions ask the Gem to do things it genuinely cannot do. A Gem cannot browse the web unless you have enabled that capability. It cannot remember anything from a previous conversation by default. It cannot access files or data you did not upload. If your instruction assumes one of these abilities, the Gem will either make something up or ignore the instruction.

Check Google's own documentation for which capabilities are available in Gems before writing instructions that depend on them. When you are not sure whether a capability exists, test it in isolation before building instructions around it.

For related Gem problems, see Gemini Gems not working for setup errors, Gemini Gems not saving for save failures, and Gemini Gem instructions character limit for length constraints.

Test with edge cases

After each change, test the Gem with inputs it is likely to receive, including the awkward ones. Give it an input that is ambiguous. Give it a short, terse input and a long, detailed one. Give it an input that is slightly outside its stated purpose. This tells you where the boundaries of the instructions are and where the model still has room to guess.

Keep a short list of your test inputs. When you change an instruction, run the same inputs again. If a fix for one case breaks another, you need to know that before the Gem is in use.

How to do this with fenbs

1. Create a free account and add a new project for your Gem or the workflow it supports.
2. Add a Skill in fenbs with the current working version of your Gem instructions. Include the test inputs you used and the expected outputs.
3. Record each rule as a Decision and rules entry: what the rule says, why it exists, and when it was last confirmed to work.
4. When a Gem breaks after an edit, open the Skill in fenbs to see the last version that worked and the reasoning behind each change.
5. Share the project with teammates so they can read the rationale before editing instructions, rather than starting from the output alone.

For a broader look at how instructions work across AI tools, see Copilot instructions not working, or compare how different platforms handle Gem-style setups in Claude Projects vs. Gemini Gems.