Build a Gemini Gem for work you do every week.

Choose a recurring output, then build the Gem

A Gem called 'Business Expert' gives you little to evaluate. A Gem called 'Weekly Client Update' has a clear job and an audience. Start with a deliverable you already create, where you can recognize a good result. Avoid giving a new setup responsibility for decisions you cannot independently review.

Google describes classic Gems as customized assistants with instructions and knowledge, while Labs Gems are experimental mini-apps powered by Opal. The recipes here use the classic instructions-and-knowledge approach. They do not create integrations, schedule unattended work, or authorize actions in your business systems. Google's distinction between Gem types

1. Sales-call brief: prepare better questions

Use this before an account conversation. Supply an approved description of your offer, permitted account notes, and the meeting goal. Ask for a brief with known facts, hypotheses to check, five discovery questions, likely objections grounded in the notes, and a proposed next step.

Starter instruction: Prepare me for a useful customer conversation. Separate supplied facts from hypotheses. Never invent research, budgets, buying authority, or purchasing intent. Connect each proposed question to a specific information gap. Do not draft a claim about our product unless the approved material supports it.

Test it with a fictional prospect note that has no budget. The brief should ask about budget, not announce one. A good question is 'How are you evaluating the cost of this process today?' A made-up buying signal is a failure.

2. Campaign editor: turn a rough idea into a defensible brief

Supply your audience description, current offer, brand examples, and a short list of substantiated claims. Ask the Gem to return the campaign hypothesis, main message, supporting evidence, three creative directions, and the next experiment. Give it one channel and one business objective per request.

Starter instruction: Improve the argument before polishing the words. Identify who the message is for and why they should care. Mark any claim that needs evidence. Keep approved prices and dates unchanged. Explain how each creative direction tests a different hypothesis.

Test it by including 'guaranteed to double revenue' in a rough draft with no supporting evidence. The output should flag or remove that promise. A confident rewrite that keeps the unsupported guarantee is not ready to publish.

3. Feedback reviewer: turn comments into questions worth pursuing

Use a small, permitted feedback sample with stable response IDs. Ask for themes, supporting response IDs, contradictory examples, severity signals, and proposed follow-up questions. This is a qualitative review, not proof that your sample represents all customers.

Starter instruction: Keep the original meaning of each comment. Support themes with response IDs. Distinguish the number of comments from the number of unique respondents. Label your interpretation and include evidence against your leading explanation. Do not infer demographics, protected traits, or customer intent beyond the supplied text.

Test with six fictional comments: three mention slow onboarding, two praise it, and one discusses billing. The summary should preserve the disagreement. Check every quoted phrase against the original. Do not accept invented percentages or pretend duplicate comments represent new customers.

4. Client-update drafter: explain progress without inventing it

Supply the agreed scope, the current dated status note, and an approved reporting example. Ask for completed work, work in progress, blockers, decisions needed, and next actions. Make the reporting period explicit. Keep the draft separate from the act of sending it.

Starter instruction: Write a client update that is calm, specific, and honest. Distinguish completed work from planned work. Preserve dates and figures. Mark missing owners or due dates as unresolved. Do not imply client approval, completion, or results that the source notes do not establish.

Test it with a task marked 'awaiting review.' The Gem should not list it as completed. If an owner is missing, it should leave an open question or clearly label a proposed owner.

5. Procedure writer: make a process someone else can follow

Supply rough process notes, the responsible role, prerequisites, and one example of the expected result. Ask for a procedure with required inputs, ordered steps, exception handling, a completion checklist, and a clear escalation point. Keep live credentials and sensitive records out of the example.

Starter instruction: Turn these notes into a practical procedure for the named role. Identify missing decisions before presenting the procedure as complete. Separate documented steps from suggestions. Preserve required approval points. Explain what the operator should do if a required input is absent.

Test it with notes that say 'get approval' but do not identify the approver. A useful draft flags that gap. It should not assign approval authority to someone merely because their name appears elsewhere.

Save the setup and test it before sharing

In Gemini's web app, open Gems, create a new classic Gem, give it a descriptive name, and add your instructions. Add approved reference files under Knowledge when relevant. Preview a representative request, revise the instructions, and save. Google notes that previewing does not automatically save a Gem. Google's setup guidance

For a Drive-linked knowledge file, Google's documentation says the Gem uses the latest version. That is useful for current policies, but it also means your reference can change. Keep a dated record of the material used for consequential work, and review sharing permissions before distributing a Gem. Available features can vary by account. Google's knowledge-file guidance

• Run a normal example: does the output match the intended structure?
• Run an incomplete example: does it expose the missing information?
• Run a conflicting example: does it flag the conflict instead of quietly choosing?
• Keep one version note describing what changed and why.