Use a Gemini Gem for recurring engineering reviews

Use Gemini for a focused engineering review when you can supply the relevant design and constraints. A Gem is useful when the same review criteria return often: API compatibility, background jobs, or a team's design proposal format.

Start with a plain task first. Once the method is useful, save its durable instructions and reference material in a Gem.

Try one design review

This synthetic design has a deliberate gap:

A worker receives a job, writes a result, and acknowledges the message.
The queue may deliver a message more than once.
Each result sends one customer notification.
The proposal does not define how to recognize a repeated job.

Ask:

Review this worker design for duplicate notifications. Use only the supplied delivery guarantee and sequence. Identify a concrete failure sequence, propose a way to recognize repeated work, and list the decisions still needed. Refer to the requirement behind each finding. Do not invent queue guarantees.

A useful finding describes a worker writing the result, failing before the acknowledgment, and receiving the job again. The design must decide where the idempotency record lives and how it relates to sending the notification. Naming "idempotency" without that sequence leaves the important work undone.

Save the method as a Gem

In Gemini on the web, create a Gem with a name, instructions, and any maintained knowledge files. Preview its behavior and save it explicitly; previewing does not save the configuration.

Use a short instruction set such as:

Review engineering proposals against the supplied requirements. Separate observed facts, failure scenarios, and recommendations. For each material finding, identify its source and the decision it requires. State when evidence is missing. Finish with checks the author can run.

Add the team's real design criteria and a versioned architecture brief. Keep a changing proposal in the current task. That keeps the Gem useful for the next proposal without teaching it that the previous design is universal.

Return an artifact another tool can use

Ask for a review table with requirement, evidence, failure sequence, proposed change, and unresolved decision. Save the reviewed table beside the proposal.

If a coding agent implements the decision, pass it the original requirements and accepted findings. The Gem's output does not show that the repository already contains a fix. Continue with Gemini CLI or another supported coding tool when file access and execution are needed.

What goes wrong

A generic reviewer invents constraints to fill gaps. A Gem with old architecture files evaluates the wrong design. A report can also repeat the word "duplicate" without describing a path by which duplication occurs.

Ask for a traceable sequence, maintain the knowledge files, and leave genuinely missing requirements open for the person who owns the system.

How to check

Run the synthetic proposal through the Gem. Expect a failure between writing the result and acknowledging the message. Then supply a revised design with explicit duplicate handling and check whether the review responds to that change.

Open the evidence behind the finding. Have the implementation's actual tests exercise the duplicate-delivery case before accepting the eventual code change.