Save your weekly task in Gemini as a Gem or a skill
Every Monday you paste the same instructions above new notes: the headings, the tone, the rule about not inventing owners. And every Monday you forget one of them. Save the brief in Gemini once, test it on a week you already know, and check the new week’s draft.
What you'll make
a saved Gemini brief for one weekly task, tested on last week’s notes, plus a checked draft for this week.
What you'll need
a Gemini account with Gems or skills, notes you’re allowed to use there, and about 20 minutes. Gems are being replaced by skills: for personal accounts from November 2026, Workspace business, enterprise and non-profit accounts from March 2027, and education accounts from June 2027. Google moves your instructions across automatically. Keep a plain copy of the brief anyway; it is the part that survives any interface change.
Example result.
What changed: integration checks finished Thursday; two minor defects
remain, fixes expected next week (timing unconfirmed).
Decisions needed: training before or after launch. Owner: to confirm.
Watch list: supplier's April position unresolved; the call suggests
it's workable, Jo's earlier note records concerns.1. Choose one repeated output
Pick a task whose shape stays the same while the facts change, such as a weekly operations update. Name the reader and what they do next. Then split last week’s brief: audience, headings, tone and rules about missing information stay; dates, figures and decisions arrive fresh each week.
A brief called “Everything at work” is hard to maintain. “Weekly ops update” gives you a specific result to check.
Why this works: build the brief for the shape of the output, never for the substance of the decision.
What you should see: a short list of stable rules, with no facts from any particular week.
2. Save the brief
If your account shows Gems: at gemini.google.com, open the sidebar and select Gems (for your first one, go to Settings and help › Gems), then New Gem. Enter a name and the instructions, then Save.
If your account has skills: select Settings, then Skills in the sidebar, and choose Create manually. In a chat, call it by typing / and the skill’s name.
Help me draft the weekly [team or project] update for [audience].
I will supply this week's notes in each conversation.
Use these headings:
- What changed: up to four short bullets
- Decisions needed: decision, owner and date if supplied
- Watch list: unresolved risks and conflicting notes
Use only the current notes for current facts. Plain UK English. Do not
add an owner, date, figure or commitment; write "to confirm" when one
is missing. Do not turn "expected" into "confirmed". If notes conflict,
show the conflict instead of choosing. If a section has nothing, say
"Nothing in the supplied notes".[team or project] and [audience] name whose update it is and who reads it.
If you use Use Gemini to re-write instructions, compare the longer version with yours and remove any task or promise you didn’t intend.
Why this works: a fixed format makes checking repeatable. The rules target the errors weekly updates usually contain.
What you should see: a saved Gem or skill with your instructions, and a plain copy in your own notes.
3. Test it on last week, not this week
Use the preview box on the right of the Gem editor, or a new chat with your skill, and paste notes from a week where you know the right answer. Testing on this week’s live notes tells you whether the output is confident, not whether it’s good.
Check that it uses your headings, keeps dates and uncertainty, leaves missing owners as “to confirm” and leaves empty sections empty. Then try an awkward input: two conflicting notes, or a week with no decisions. If a problem recurs, add a rule naming that exact failure. Rules written against observed failures work much better than rules written in anticipation.
Why this works: you can only judge a brief against an answer you already know.
What you should see: a draft that matches what you’d have written, and an awkward case that keeps its conflict visible.
4. Use it with fresh notes, where the work happens
Each week, open the Gem or skill and paste the new notes. A Gem made on the web also appears in the Gemini mobile app and the Gemini side panel in Google Workspace, so you can use it beside the email or sheet you’re working from.
Draft the update for [period] from these current notes only:
[this week's notes][period] is the reporting week; [this week’s notes] are the facts as you have them.
Why this works: the saved brief does the formatting, and the notes are the only source of facts.
What you should see: a three-section draft that you check against the notes before sending.
Check the result
- Every fact in the draft is in this week’s notes.
- Missing owners and dates say “to confirm”.
- “Expected” is still “expected”.
- Conflicting notes appear as a conflict on the watch list.
The usual failure: a conflict is quietly resolved into the tidier version, such as “Supplier confirmed April”, or a person mentioned near a decision becomes its owner. Spot it by checking every status word and every name in the draft against the notes.
Revise this draft against the notes. Remove [unsupported item].
Keep [uncertainty or conflict] visible. Do not change other supported
facts. List the changes for me to check.[unsupported item] is the line with nothing behind it; [uncertainty or conflict] is what the notes really say. If you’d want the same rule next week, add it to the saved instructions; a Gem doesn’t learn from corrections in chat.
Worked example: the Monday update
Fictional example. This week’s notes:
Period: 28 September to 2 October 2026.
Integration checks finished Thursday. Two minor defects remain;
fixes expected next week, not yet confirmed.
Supplier call: April looks workable. An earlier note from Jo records
supplier concerns about April. Nobody has resolved the difference.
Training before or after launch needs a decision. No owner or date set.The first draft’s watch list said “Supplier confirmed April”, and the training decision was assigned to Jo. Neither is in the notes. After the repair prompt, the draft matched the example result above.
What mattered:
- The tidy version was the wrong one. “Supplier confirmed April” is the most tempting edit in the input, and the one that would cause a problem in the meeting.
- A named author isn’t an owner. Jo wrote a note; nobody gave Jo the training decision.
- The rule went into the brief. “Never assign an owner the notes don’t name” was added to the saved instructions, so next Monday starts with it.
The next week, if the notes say the supplier has confirmed April in writing, the item should leave the watch list. Check that it does; an old conflict that never goes away is the same problem in reverse.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Build a second Gem that only checks
For anything consequential, a separate checker is more useful than making the first brief longer. Save this as its own Gem or skill, then paste the notes and the draft together:
You audit drafts against their source notes. You never rewrite.
For each, list what you find or write "none":
- an owner, date or figure in the draft that is not in the notes
- a hedge in the notes that became a commitment in the draft
- a conflict in the notes that the draft resolved silently
- anything in the notes the draft dropped
Quote the relevant line from the notes for every item.It’s still another draft, not an independent witness, but separating writing from checking catches more than one prompt trying to do both.
When not to build one
Skip it when the task varies more than it repeats; if you override the instructions most weeks, you’ve built a constraint, not a shortcut. Skip it when the brief would encode a judgement that should stay human, such as deciding which complaints are serious. And don’t build one for anything about people’s circumstances: performance, conduct, health, pay, complaints or employment decisions.
A Gem is saved instructions. It isn’t trained on your work, doesn’t remember last week unless you paste it, and doesn’t change your organisation’s rules about what you can share.
Attach a reference file
In the Gem editor, select Knowledge › Add files and upload a style guide or glossary, or add it from Drive. Adding from Drive needs Keep Activity on and Google Workspace connected to Gemini; a device upload is a snapshot that goes stale. Leave citations on so you can see which part of the file an answer used. Skills don’t yet support adding files from Drive, so check before you migrate a Gem that depends on one.