Build and Iterate on Gems

A Gem is a saved set of instructions that Gemini loads every time you open it. Instead of re-explaining your role, your audience, and your preferred format at the start of every conversation, you write that once and then just send the input.

Most people who try Gems write one, get a mediocre result, and go back to normal prompting. The reason is almost always the same: they wrote the Gem once and never fixed it. A Gem is not something you write. It is something you refine over a handful of real uses until it stops disappointing you.

This lesson builds one from scratch and then breaks it on purpose, because the fixing is the part that matters.

What Belongs in a Gem

Five elements cover nearly every useful Gem:

ROLE: What expert Gemini should act as

CONTEXT: Background it needs every time, about you,
your work, your audience, or your product

TASK: What to do when you send a message

FORMAT: The exact structure of the output

RULES:
- Specific things to always do
- Specific things to never do

CONTEXT is the element people leave out, and it is where most of the value sits. Anything you would find yourself re-typing at the start of every conversation belongs there.

Build One: A Lesson Feedback Gem

Say you teach, and you want quick feedback on lesson plans before you use them. A first attempt might look like this:

ROLE: You are an experienced teacher.

TASK: When I paste a lesson plan, give me feedback on it.

FORMAT: A list of suggestions.

This will produce something. It will also produce the same generic advice for every lesson plan you ever paste, because you have not told it what good means to you or who the lesson is for.

Test It Honestly

Now run it on three real lesson plans, not one, and not invented ones. Three is the minimum that shows you a pattern rather than a coincidence.

Read the outputs and mark the specific ways they disappoint you. Typical findings:

• It praises everything before it critiques anything, so the useful part is buried
• It suggests activities that need equipment you do not have
• It ignores that your students are beginners
• The feedback is a wall of prose when you wanted something you can scan

Each of those complaints translates directly into an instruction. That translation is the whole skill.

Fix What You Found

ROLE: You are an experienced teacher who reviews lesson
plans and gives direct, practical feedback.

CONTEXT: I teach introductory classes to adult beginners
with no background in the subject. Class size is 20 to 30.
Sessions run 50 minutes. I have a projector and a whiteboard,
no lab equipment, and no budget for materials.

TASK: When I paste a lesson plan, review it and tell me
what will not work and how to fix it.

FORMAT:
## Biggest risk
One paragraph on the thing most likely to go wrong.

## Specific problems
A short list. For each one, name the problem and the fix
in the same line.

## What is working
Two bullets maximum.

## Timing check
Whether the plan fits 50 minutes, and what to cut if not.

RULES:
- Lead with problems, not praise
- Never suggest activities needing equipment or budget
- Assume no prior knowledge in the students
- Be concrete. "Add an example" is useless. Name the example.
- If the plan is solid, say so in one line and stop

Run your three lesson plans through again. The outputs should now be noticeably more useful, and you will find a second, smaller round of complaints. Fix those too. Two or three rounds is normal, and after that a Gem tends to stay good for months.

The Rules That Carry the Most Weight

Across many Gems, a few kinds of instruction do most of the work.

Negative rules. "Never suggest activities needing equipment" prevents a whole category of bad output. Listing what to avoid is usually more effective than describing what you want, because models drift toward generic helpfulness unless told not to.

Stopping conditions. "If the plan is solid, say so in one line and stop" stops a Gem padding when there is nothing to say. Without it, an assistant asked for problems will invent problems.

Concreteness demands. "Name the example" converts vague advice into usable advice. Any time you catch yourself thinking "that is technically true but I cannot act on it," add a rule demanding specifics.

Length limits. "Two bullets maximum" is what makes output scannable. Models are generous by default and you have to say otherwise.

When a Gem Is the Wrong Tool

Gems are for repeated tasks with a stable shape. They are a poor fit when:

• You do the task rarely. A one-off prompt is less work than building and tuning a Gem.
• Every instance is genuinely different. If the format changes each time, you will fight the Gem's instructions instead of being helped by them.
• The task needs a long back-and-forth. Gems set up the opening move well, but a real exploratory conversation does not need one.
• You need current information. A Gem carries instructions, not knowledge. It does not know anything the model does not already know.

That last point catches people. A Gem cannot make Gemini aware of your company's internal documents. It can only tell Gemini how to behave when you provide them.

Keeping Gems Useful Over Time

Build a small number of Gems you actually use rather than a library you forget about. Three well-tuned Gems beat fifteen abandoned ones.

Give each a name that says when to reach for it. "Lesson plan reviewer" is findable. "Teaching helper" is not, especially once you have four Gems with similar names.

Revisit a Gem when its output starts annoying you again. That irritation is information: something about your work changed, and the instructions have not caught up yet. Open it, add the rule, move on.

Key Takeaways

• A Gem is refined over several real uses, not written once and abandoned
• ROLE, CONTEXT, TASK, FORMAT, and RULES cover nearly every useful Gem, and CONTEXT is the most skipped
• Test on at least three real inputs so you see a pattern instead of a coincidence
• Turn each specific complaint about the output into a specific instruction
• Negative rules, stopping conditions, concreteness demands, and length limits do most of the work
• Skip the Gem for rare, highly variable, or exploratory tasks, and remember it carries instructions rather than knowledge
• Keep a few well-tuned Gems with findable names, and update one whenever its output starts annoying you