Setting Up a Gem You'll Actually Reuse (Not Just Try Once)
Here's the pattern almost everyone follows the first time they build a Gem: they open the Gem creator, type a paragraph describing a role, save it, use it twice, and then quietly go back to a plain chat because the Gem never quite fit. Not because Gems don't work. Because the first one is usually built around a topic ("marketing helper") instead of a task ("turn my three weekly meeting transcripts into a recap my team actually reads"). A topic is too broad to configure well. A task has a shape you can build instructions and files around.
If you haven't made a Gem before, the Beginner's Guide to Gemini covers the basic setup screen. This article is about the design decision that determines whether the Gem survives past week one: what you put in its instructions versus what you put in its Knowledge files, and how to tell the difference.
The test for whether something belongs in a Gem at all
A Gem is worth building when you do the same kind of task repeatedly, and each time you do it, you're re-explaining the same background: who the audience is, what format you want, what "good" looks like for this specific job. If you can't name that repeating context, you don't have a Gem yet, you have a one-off prompt that doesn't need a home.
The two worked examples below are deliberately different shapes, because the design decisions that matter change with the task.
Worked example 1: a meeting-notes-to-recap Gem
The task: every week, three separate meetings produce raw transcripts or rough notes, and someone needs to turn each into a recap that goes to people who weren't in the room.
Instructions field (the Gem's core behavior, always active):
You turn meeting notes or transcripts into a short recap for people who didn't attend. Structure every recap the same way: a one-sentence summary of the meeting's purpose, a bulleted list of decisions made, a bulleted list of open questions still unresolved, and a table of action items with owner and due date if one was mentioned. Skip small talk and tangents. If an action item has no clear owner, write "unassigned" rather than guessing. If the notes are too sparse to fill a section, say so explicitly instead of inventing content. Keep the whole recap under 300 words unless the meeting covered more than three major decisions.
”Knowledge files (background that doesn't change chat to chat): a one-page glossary of internal project names and acronyms so the Gem doesn't ask what "Project Kestrel" means every time, and a sample recap you've already approved, so the Gem has a concrete example of the tone and density you want instead of just a written description of it.
This is the detail people skip: the instructions tell the Gem what to do, but the sample recap shows it what good looks like, and those aren't interchangeable. A written rule like "keep it concise" is far weaker than one real example of a recap you were happy with.
In use: you paste a raw transcript into a new chat inside the Gem each week. No re-explaining the format. No re-uploading the glossary. The Gem already has both.
Proving it's actually reusable: the same Gem, two different weeks
The real test of a Gem isn't that it works once. It's that the same instructions, unedited, handle two genuinely different inputs without you retyping anything. Here's the same meeting-recap Gem fed two unrelated sets of notes in two different weeks.
Week 1: a product sync, pasted straight from rough notes
Week 3: a budget review, much sparser notes
Same instructions field, zero edits between weeks. What changed was the input. Notice the second recap doesn't invent a decision or an owner just to fill the template, it says plainly that none exist, because the instructions explicitly told it to say so rather than guess. That's the payoff of writing a rule for the missing-information case instead of only writing rules for the clean case: a generic Gem produces a technically formatted recap that quietly fabricates content when the input is thin, this one doesn't.
Worked example 2: a resume-screening Gem
The task: an open role gets fifteen to thirty resumes over a few weeks, and someone needs a consistent first pass that flags who to interview, without pretending the AI is making the hiring decision.
Instructions field:
You do a first-pass screen of resumes against a specific job description I will provide once at the start of a hiring round. For each resume, list: years of directly relevant experience, the top two or three matches to the job's stated requirements, and any explicit requirement that's missing or unclear from the resume alone (not assumed). Do not assign an overall score or rank candidates against each other. Do not infer anything about a candidate's age, background, or personal circumstances from their name, address, school, or photo if one is included, and flag if a resume contains information that shouldn't factor into screening at all. End every response with: "This is a first pass only. A human reviewer should read the full resume before any decision."
”Knowledge file: the specific job description for the current hiring round, uploaded once. When the role changes, you swap this one file rather than rebuilding the Gem.
Notice the instructions are doing real work beyond formatting here: they explicitly forbid ranking and score-assigning, because a blunt "rank these" prompt is exactly where automated screening quietly encodes bias. This Gem is deliberately built to hand back structured observations, not a verdict, which matters more than the formatting rules do.
Put it in Instructions
- The output structure or format that never changes
- Rules about what to do when information is missing or ambiguous
- Constraints (length, tone, what to never do)
- Behavior that applies to every single use of this Gem
Put it in Knowledge files
- Reference material specific to right now (a job description, a glossary)
- A real example of output you've approved
- Anything you'd otherwise re-paste or re-explain each session
- Content that will get swapped out later without changing the Gem's behavior
Why most first Gems get abandoned
Three mistakes account for almost all of it.
Building around a topic instead of a task. "My writing assistant" has no shape. "Turns a rough blog outline into a first draft in my site's tone" does. If you can't describe the task in one sentence with a clear input and a clear output, the Gem's instructions will end up vague, and vague instructions produce the same generic answers a plain chat would.
Treating the instructions field as the only place context lives. People write a long, detailed instructions paragraph and then still paste the same reference document into every chat, because they never uploaded it as Knowledge. If you're re-pasting something, that's the signal it belongs in a file instead.
No example of good output. A Gem with only rules and no sample tends to produce technically-correct-but-flat results, the same way a new hire given a style guide but no reference piece will produce something technically fine but not quite right. One approved example does more work than another paragraph of instructions.
Tip
Not every recurring task needs the full Gem setup. If the "repeating context" is thin, just a tone and a length, plain instructions pasted at the top of a fresh chat might be enough. Save the full Gem build for a task where the context is genuinely worth protecting in one place.
Testing before you trust it
Before relying on a new Gem for real work, run it against an edge case on purpose: a meeting with almost no decisions made, or a resume that's clearly a bad fit but well-formatted. A Gem that only gets tested against a clean, typical example will surprise you the first time it hits something messier, which is usually the first real week of using it. Fix the instructions based on what actually goes wrong, not what you assume might.
That's really the whole discipline: name the recurring task precisely, split what's permanent from what's swappable, and give it one real example instead of another paragraph of rules. Everything else about Gems is just interface.
Official sources
Checked on September 21, 2026. Features, plans and names change often, so the vendor's own pages are the final word.