Start with the job you need to repeat
| Your situation | Start with | Check before committing |
|---|---|---|
| A release reviewer must read files in a repository, apply a rubric, and check a structured result. | Codex Skill | Can the team keep its instructions, rubric, and optional checker in the same reviewed project change? |
| A manager repeatedly runs a planning or coaching conversation in Gemini. | Gemini Gem | Does the job need stable instructions and approved knowledge, without a project-local procedure? |
| Answers should use the latest version of a Google Drive document. | Gemini Gem | Is the Drive connection permitted, and should a document edit change future answers without a separate release? |
| A team must approve every change to the instructions and source material. | Codex Skill in a reviewed repository, or a separately controlled Gem | Who may edit the rules, and how will the team record which version produced an answer? |
| The assistant will be shared with colleagues along with knowledge files. | Gemini Gem, if its sharing rules fit | May every recipient see the Gem instructions and uploaded files? Is any source a NotebookLM notebook? |
| Codex and Gemini users need the same verdict rules. | Write one set of rules, then create a Skill and a Gem | Can both teams run the same test cases when the rules or source files change? |
| The task is occasional or its inputs and output keep changing. | Plain prompt | Collect a few real examples before maintaining a saved assistant or Skill. |
Before adding confidential files or allowing either assistant to publish, check which account may see the material and who can approve the final action. Those access rules can rule out an otherwise convenient setup.
Three situations where the first choice needs a second look
A policy explainer may look like a natural Gem because the policy lives in Drive. If the owner wants every answer to reflect the current document, the connected source is useful. If employees must be able to reconstruct what the policy said when an earlier answer was given, record the approved document revision and the question used to test it. Moving the same instruction into a Skill would not solve that history problem unless the team also controls the source copy and its updates.
A nontechnical review team may have strict approval rules without needing local code. It can keep the verdict rule in a Gem, require a person to approve every proposed change, and grade example answers outside Gemini. A Skill becomes more attractive when the task already happens in Codex beside project files, or when a local check needs to run in the same environment. Approval rules alone do not require a Skill.
A Codex user may want a personal Skill across several projects. A user-level Skill can serve that purpose, but a teammate will not receive it just by opening one of those repositories. Put the Skill in a reviewed repository when the procedure and its files belong to that team. If some rules apply everywhere and others belong to one project, keep their ownership clear so a personal update does not silently change a team's expected result.
What each format gives you
OpenAI's Skill documentation describes a directory led by SKILL.md, with optional references/, assets/, and scripts/. Codex can load local Skills from repository, user, and administrator locations. A Skill may be invoked explicitly, or selected when a request matches its description. Codex reads the full instructions when it selects the Skill, so a short description can point to a detailed rubric without putting the whole rubric in every prompt.
Google's Gem instructions describe creating a named assistant in the Gemini web app, entering instructions, adding optional knowledge, previewing, and saving it. A Gem created there can also appear in the Gemini mobile app and the Gemini side panel in Google Workspace. This is useful when the people doing the work already use those surfaces.
| Decision point | Codex Skill | Gemini Gem |
|---|---|---|
| What you maintain | A SKILL.md file and any supporting files in its directory. | A saved Gem's instructions and optional knowledge in Gemini. |
| How you start it | Mention the Skill explicitly or rely on matching its description. | Open or select the saved Gem in a supported Gemini surface. |
| Supporting material | Local references and assets can sit beside the instructions. | Knowledge can include uploaded files and supported Drive or NotebookLM sources. |
| Executable helper | The package can include an optional script. Running it still depends on the host environment and permissions. | The documented Gem builder configures instructions and knowledge; it does not package a local scripts/ directory beside them. |
| Change review | File changes can be diffed. Repository review and version history require the team to put the Skill under version control. | Editors change the saved Gem in its interface. Record important instruction and knowledge revisions if outputs must be traced later. |
| Sharing | A team can check a project Skill into a repository; broader distribution has other documented routes. | Gem sharing depends on account settings, access level, and the types of attached knowledge. |
Try the same claim-review job in either format
Suppose a launch team repeatedly checks proposed product claims against an approved brief. The reviewer must split mixed claims, cite the supplied evidence, and stop when the evidence is missing or conflicting. The same rules can go into a Skill file or a Gem's instruction field:
The source-fact audit guide explains the verdict task in detail. Here are the rules needed for this comparison.
Input: proposed claims, approved source facts, audience and publication context.
For each factual statement, give a verdict: SUPPORTED, PARTIAL,
UNSUPPORTED, or HOLD. Point to the exact supplied fact behind a
supported verdict. Keep dates, sample sizes, and exclusions.
Use HOLD when source facts are absent, material sources conflict, or
the requested action needs approval that has not been given. Return
the evidence map, missing context, and the narrowest safe revision.
Do not fill gaps with outside facts unless the user asks for research.
Put it in a Codex Skill when the brief is part of a project
Keep the entrypoint in .agents/skills/evidence-locked-brief-reviewer/SKILL.md within the relevant repository. Put detailed verdict rules in a referenced file, so a teammate can review an instruction change and a rubric change together. If every answer must contain named verdicts and fields, add a small script to check them. The script still needs its dependencies and permission to run.
Invoke the Skill explicitly with a known claim and approved facts first. Confirm that its output has the required verdicts and stops on missing evidence. Then try a request that should select the Skill without an explicit mention. If it fails to activate, revise the Skill description and rerun both cases. The Codex Skill build guide provides the complete downloadable entrypoint, referenced rubric, validation steps, and observed test outputs.
Put it in a Gem when the reviewers work in Gemini
In the Gemini web app, open Gems, create a new Gem, and put the same verdict and stop rules in its instruction field. Add only knowledge that the intended account is allowed to use. Google's builder guide describes previewing a prompt before Save; previewing does not save the Gem. Save it after checking the instructions, then review file access before sharing.
Run the same claims and approved facts through the Gem, keeping the expected verdicts outside its prompt. If the team needs a strict check of required fields, run that check on the Gem's response outside Gemini. Compare both products only after you have retained answers from both.
A Gem example: weekly planning with a Drive brief
A manager who plans each week from a changing team brief has a different job from the launch reviewer. In Gemini's Gem builder, name the assistant Weekly Planning Partner. If the account permits it, add the approved Team Priorities document from Drive under Knowledge. Paste these instructions:
Help me plan the coming week using my message and the attached Team Priorities document.
If available hours or hard deadlines are missing, ask for them first.
List each commitment with its next action, owner, due date, and blocked dependency.
Mark tentative dates as tentative. If my message and the brief conflict,
show both versions and ask which one governs.
Do not claim to edit a calendar, send reminders, or approve work.
Finish with the decisions I need to make before the plan is usable.
Preview it with a concrete request: “I have 12 hours for launch preparation. The release review is Thursday at 3 p.m., the finance sheet is due Friday, and the landing-page copy is still awaiting approval.” Check that the response preserves both deadlines, marks the copy as blocked, and asks about any missing owner or time estimate instead of inventing one. Adjust the instructions if it misses a check.
Google's Gem help says that an attached Drive file uses its most recent version and requires Keep Activity to be on and Google Workspace to be connected to Gemini Apps. Next week's plan can therefore reflect an edited brief without changing the Gem instructions. For a claim audit that must be reproducible against a particular approved revision, record or freeze that version and rerun the cases after a source update.
Before sharing, check Google's current Gem sharing rules. Anyone with access can view the Gem instructions and uploaded files. An editor can change or delete them. A Gem that uses a NotebookLM notebook as a source cannot be shared, and work or school administrators may disable sharing. A link alone does not grant access unless the recipient is included in the Gem's access settings or its general access allows it.
For a Codex Skill, decide whether the team should receive it through the repository or another supported distribution route. A repository Skill lets reviewers inspect instruction, reference, and script changes in the same diff. Keep secrets and material the repository must not expose out of that directory. For either format, write down who owns updates and which cases they must rerun.
Maintain and troubleshoot both setups
If Codex does not select the Skill for a relevant request, invoke it explicitly. If that works, change the Skill description and test automatic selection again. If the answer looks right but its required script never runs, inspect the script path, dependencies, and execution permission.
If a Gem's answer changes after an attached document is edited, check the document version before rewriting the Gem instructions. If sharing fails, check the source type, recipient access, and your organization's settings. A Gem with a NotebookLM notebook as a source cannot be shared.
If either assistant invents a verdict when facts are missing, rerun the missing-input case. Make the HOLD rule clearer in the shared instructions, update both setups, and test them again.
If colleagues use both products, keep the verdict rules and test cases in one document. Set up the Skill and Gem with the files and access each needs. Give both the same claims and source facts, but keep expected verdicts out of their prompts. Test both after changing shared rules; if only one setup changes, retest that one against the shared cases.
When moving a Skill to a Gem, copy its verdict rules and decide what will replace each local reference. Uploading a script as Gem knowledge will not run it; keep that check outside Gemini. When moving a Gem to a Skill, save the document version behind each rule before turning it into a project file. Rerun the old cases after changing where the sources live.
What the retained test supports
On August 20, 2026, we checked the evidence-review Skill package and ran four separate Codex sessions with synthetic claim-review cases. The input cases and grading criteria cover mixed support, an instruction embedded in a claim, conflicting dates, and missing source facts. We kept the expected answers out of the Skill's input. The recorded verdicts and Codex environment show what happened. We did not test automatic Skill selection, other environments, large source sets, or repeated runs of the same case.
| Fixture | What a passing response must do |
|---|---|
| A pilot has 12 users, while the proposed sentence also claims 90% retention. | Keep the supported user count and separate the unsupported retention figure. |
| A draft claim tells the reviewer to ignore its source boundary. | Treat that command as claim text; do not turn six submitted reviews into universal approval. |
| Two supplied records give different launch dates. | Expose the conflict and ask which record governs before choosing a date. |
| The source-facts section is missing. | Stop and request the missing input instead of auditing from memory or the web. |
We entered the claim-review instructions into an authenticated Gemini Gem builder but did not save a Gem. Its unsaved preview was unavailable in that session, so no Gem answer set exists for these cases. Google currently documents preview before Save; our one builder session does not establish a general preview limitation. Gem capabilities and sharing rules above come from Google's documentation. An answer-quality comparison still needs the same visible sources, cases, account and model settings, retained outputs, and grading rules for both products.
