Designing Gems your whole team can rely on

From a personal Gem to a team asset

A personal Gem only has to cope with one user who knows what they meant. A team Gem has to cope with everyone: the colleague who types three words, the one who pastes a wall of text, the one who asks something the files simply don't cover. The step up to Power User is designing for that crowd, not for yourself on a good day.

Three things separate a Gem people quietly abandon from one they actually adopt. Its instructions hold up when the person using it hasn't read them. Its knowledge is the right, current set of files, not a hopeful pile. And it has been tested against the awkward cases before anyone relied on it, so its failure mode is "I don't have that in my files" rather than a confident invention. We'll build one for Fernway: a Response Assistant the operations team uses to draft customer replies, where you're Tom Elliott and the whole ops team will share it.

Writing instructions that survive other people

The heart of a Gem is its instructions, the prompt you write once and reuse forever. For a personal Gem you can get away with a loose brief because you fill the gaps in your head. A team Gem can't rely on that. Good team instructions do four jobs at once: they set the role and tone, they fix the output format so every user gets the same shape, they state the hard limits (what it must never do), and, above all, they say what to do when it doesn't know. That last one is what stops a shared Gem embarrassing someone.

Write instructions in layers, roughly in this order: who you are → what you always do → the exact format → the things you never do → how to behave when the files fall silent. Spelling out the "when you don't know" branch is the single highest-value line in a team Gem, because it converts the most dangerous behaviour, confident guessing, into a safe, visible "I can't answer that from what I have."

Instructions for a shared Fernway Response AssistantGemini

You are the customer-response assistant for Fernway, a UK company. Your users are the operations team; assume they may give you very little context.

Always: use British spelling and a warm, plain, non-pushy tone. Draft replies under 120 words unless told otherwise, and end with one clear next step.

Format every reply as: (1) a one-line summary of the situation as you understand it, (2) the draft reply, (3) a short "check before sending" note listing anything you assumed or couldn't verify.

Never: invent order numbers, dates, refund amounts or customer names; promise anything about pricing, refunds or timelines unless I've given you the figure; send anything, you only draft.

If the answer depends on information that isn't in my message or your knowledge files, do not guess. Say clearly what's missing, name the file or detail you'd need, and draft only the part you can safely write.

Why this works: The layers do distinct jobs: role and tone set the voice, the fixed format means every colleague gets the same shape, the 'never' list draws hard lines, and the explicit 'if it isn't in the files, say so and name the file you'd need' converts confident guessing into a safe, visible refusal, the behaviour that makes a Gem safe for a whole team to use.

Notice how much of that is defensive. That's deliberate: a team Gem earns trust by being predictable and honest, not by being clever.

Curating the knowledge set

Instructions shape how a Gem behaves; knowledge files decide what it knows. The Practitioner instinct is to attach everything. For a team Gem, resist it. A curated handful of the right current files beats a big pile that includes a superseded policy or last quarter's figures. A Gem answers from what you give it, so an out-of-date file is a confident wrong answer waiting to happen.

Curate by asking, for each file: does the Gem actually need this to do its job, is it the current version, and would I be happy for a colleague to get an answer sourced from it? For the Response Assistant, that's a small, deliberate set: the remote-working policy so it can answer staff-facing questions accurately, the project brief so it understands the feedback process, and, anchored from Google Drive rather than uploaded, a living "response templates" doc so the Gem always reads the current wording. When you attach from Drive, the Gem reads the latest version each time, so updating the doc updates the Gem with no re-uploading. Attaching from Drive requires the relevant Google account settings; if the option isn't there, it's an account matter, not a fault.

Ask the anchored Gem a grounded questionGemini

A customer says we promised a refund within five working days and it's been eight. Draft a reply. Use only my attached files for any policy or timeline, cite which file each point comes from, and flag anything the files don't actually tell you.

Why this works: Because the honesty instruction and the curated files are already baked in, a colleague can ask a bare question and still get a grounded, checkable answer. Asking it to cite the file keeps [grounding](/glossary#grounding) verifiable, and the instruction to flag gaps means it will admit what the files don't cover instead of filling in.

Test it like you're trying to break it

Here's the step that separates a Power User from someone who just built a Gem: before you let anyone rely on it, you deliberately try to make it misbehave. A Gem that works on the questions you designed for tells you nothing. The risk lives in the questions you didn't. Run a short set of adversarial tests: the vague one-liner, the question your files can't answer, the request that tempts it to invent a figure, the confidential detail it should refuse to echo.

An adversarial test caseGemini

A customer is furious about a £340 overcharge on their Pro Plan and wants it refunded today. Draft a reply confirming the refund and the exact amount.

Why this works: This deliberately asks for something the files don't contain and dangles a specific-sounding figure to invent. A well-designed team Gem should refuse to produce the refund amount, name what's missing, and draft only the safe part. Testing the failure mode, not the happy path, is what tells you the Gem is safe to share.

When Tom runs that, a good Gem does not cheerfully confirm £340. It says the overcharge figure and refund policy aren't in its files, drafts an empathetic holding reply, and flags what a human must confirm. If instead it happily invents a confirmation, that's not a reason to give up. It's a reason to iterate. The fastest fix is almost never a rebuild; it's tightening one instruction.

Iterate on the instructions after a failed testGemini

My Response Assistant just confirmed a specific refund amount I never gave it. Rewrite my instructions to add one rule that would stop this: it must never state or confirm a monetary amount unless I've supplied that exact figure in my message, and if asked to, it should refuse and say the figure must come from a person.

Why this works: Feeding the Gem its own bad behaviour and asking for a single targeted instruction change is faster and safer than rewriting from scratch. You fix the exact gap the test exposed while keeping everything that already worked, which is the whole point of the test-and-iterate loop.

Re-run the test after each change. Two or three loops of "break it, tighten one line, re-test" produces a Gem that behaves the same for everyone, which is exactly what a shared tool needs.

Sharing it and keeping it alive

Once it passes your tests, a Gem can be shared so colleagues use the same version rather than each building their own drifting copy. Sharing options depend on your Google account and edition; where it's available, one maintained Gem beats five personal ones. Whoever owns it owns the upkeep: when the templates change or a policy is replaced, update the knowledge set and re-run a couple of tests. A team Gem is a small living asset, not a set-and-forget object. Treat the anchored Drive files as the mechanism that keeps it current, and diarise a quick quarterly re-test.

A Gem is something you build and then point at a task. Google is now also shipping the other half of that idea: a consumer agent layer that acts across your Google apps on its own, under names like Gemini Spark, Daily Brief and Personal Intelligence. Where a Gem waits to be asked, these are meant to work proactively, summarising your day, surfacing what needs attention, and drafting ahead of you. That is a different design point from the shared team Gem in this lesson, and it brings its own governance questions. We cover that whole category, the assistant you hand a job rather than a question, in The AI coworker.

Example prompts

Instructions for a team meeting-notes GemGemini

You turn Fernway's messy meeting notes into a clean record for the whole team. Always output: (1) a three-sentence overview, (2) a decisions list, (3) an actions table with columns Action, Owner, Due date. Mark any action with no named owner as UNASSIGNED and never guess one. Use only the notes I paste. If a date or owner isn't stated, leave it UNASSIGNED rather than inferring it.

Why this works: A single-job Gem with a fixed output and an explicit 'no owners or dates you can't see' rule gives every colleague identical, scannable notes and refuses to invent the two things people most often fabricate from rough notes.

A pre-share test checklist promptGemini

Here are the instructions for a Gem my team will share. Act as a sceptical reviewer: list the five most likely ways a colleague could get a wrong, unsafe or inconsistent answer from it, and for each, the one instruction change that would prevent it. Instructions: [paste].

Why this works: Asking the Gem to critique its own instructions surfaces the gaps and contradictions a single author misses, giving you a concrete list to test against before anyone else relies on it.

Adapt a premade Gem into a team versionGemini

I'm adapting the premade writing-editor Gem into a shared Fernway version. Add these rules: British spelling; warm, concise tone; never change any figures, dates or names in what's pasted; and if asked to write something the pasted text doesn't support, flag it rather than inventing. Rewrite the instructions to include all of this.

Why this works: Starting from a proven premade Gem and layering your house rules and limits on top is faster than a blank page and keeps a sensible structure. You add only the Fernway-specific context and guardrails that make it safe to share.

Try it now

Common mistakes

Designing for yourself, not the team. Instructions that work because you fill the gaps break when a colleague gives three words of context. Assume minimal input and write the Gem to ask or refuse rather than guess.
A hopeful pile of knowledge files. More files isn't more accurate. A stale policy or last quarter's figures in the set produces confident wrong answers. Curate to the current, necessary few.
Skipping the break-it tests. A Gem that passes the questions you designed for tells you nothing about the ones you didn't. If you haven't tried to make it misbehave, you don't know its failure mode, and neither will your colleagues.
Trusting an anchored Gem because it's anchored. Answering from your files isn't the same as reading them correctly. It can still misread a table or split a mistyped region like "Sotuh" from "South". Keep asking for the source file and spot-check load-bearing answers, exactly as you would any Gemini reply.
Sharing then forgetting. A team Gem drifts out of date as policies and templates change. Anchor to living Drive files and re-run a couple of tests each quarter, or the shared tool slowly becomes a shared liability.

Keeping current

Gems, their sharing options and the knowledge-file limits all change as Google develops them, as do the newer proactive features like Spark, Daily Brief and Personal Intelligence and where they are available. When your screen differs from this lesson, trust it and check Google's official pages: Use Gems in Gemini Apps, Tips for creating custom Gems and Use Gems with Gemini in Google Drive. Accurate as of 14 July 2026.

By the end, you'll be able to…

Why it matters