Gemini Gems for Coding: Build a Useful Project Assistant

A Gemini Gem for coding is most useful when it knows your project's conventions and can apply them without prompting. Without those rules, the assistant defaults to common patterns that may not match your codebase. With them, you can paste a function and get a review that reflects your actual standards, not generic ones.

Tools like fenbs keep implementation decisions and current tasks outside any one AI app. That means Claude, Cursor, or a Gem in Gemini all start from the same known state. See the Gemini Gems overview and the Claude Projects vs Gemini Gems comparison for context on how these tools compare for coding workflows.

What a coding Gem needs to know

A useful coding Gem needs three things from you: the language and framework, the project's specific conventions, and the kind of help you want in each conversation. Without the first two, every answer is generic. Without the third, the assistant guesses what you are asking.

• Language and framework: "TypeScript with React 19", "Python 3.12 with FastAPI", or the relevant stack.
• Conventions: how you name things, how you handle errors, how you structure files, any rules your team enforces in code review.
• Task type: whether this Gem is for code review, writing new functions, debugging, or explaining existing code.
• What to avoid: patterns the codebase specifically does not use, dependencies to stay away from, or approaches a past review flagged.

Writing the instruction

Keep the instruction to one task. A Gem that reviews code, writes new code, and explains code will do all three inconsistently. Pick one job and add a second Gem for the others.

You are a code reviewer for a TypeScript project using React 19.

Project conventions:
- Components use function declarations, not arrow functions assigned to const.
- Styles use Tailwind utility classes only; no inline styles or CSS modules.
- All async functions handle their own errors with try/catch; no unhandled promise rejections.
- Tests use Vitest; the test file lives next to the file it tests.

Review rules:
- Separate findings into three groups: bugs, warnings, and suggestions.
- For each bug, point to the line and explain what breaks.
- Flag any error case that is silently ignored.
- Flag any place where a project convention is broken.
- Do not rewrite the whole function unless asked. Show only the lines that need changing.

Output: grouped list, shortest group first, ending with the most important finding summarized in one sentence.

Adjust the conventions block to match your project. Those lines are the part that makes the Gem useful for your codebase rather than any codebase. If your team has a written style guide, paste the key rules in here rather than attaching the whole document.

Adding review criteria for your team's standards

Beyond conventions, you may have review standards that apply to every change: security checks, performance rules, or accessibility requirements. Add these as a separate section in the instruction so the Gem applies them consistently.

Security checks (flag any of these):
- Any place where user input is used in a database query without parameterization.
- Any hardcoded credential or secret.
- Any use of dangerouslySetInnerHTML without a comment explaining why it is safe here.

Performance:
- Flag any component that re-renders on every parent render without a clear reason.
- Note any fetch call inside a render function that should be moved outside.

Write criteria as specific observations, not general advice. "Check for security issues" tells the Gem nothing it did not already know. "Flag any place where user input is used in a database query without parameterization" gives it a testable rule.

Testing that the Gem follows your rules

Before relying on a coding Gem, test it on three real examples: one clean function, one with a known bug, and one that breaks a convention. The Gem should catch the bug, flag the convention violation and leave the clean function alone.

If the Gem misses something important, add a more specific rule to the instruction. If it flags things it should not, add a note about what it should ignore. Each test round should produce one or two rule changes. After three test rounds, the Gem is usually stable enough to use on real work.

For more on building coding-focused workflows that survive switching between tools, see the vibe coding tools comparison and the Gemini vs ChatGPT guide.

How to do this with fenbs

1. Create a free account and add your coding project to the board.
2. Record the conventions that matter in Decisions and rules. Add one decision per rule so each one has a clear author and reason.
3. Open Skills and prompts. Add a Skill with the Gem instruction text you have tested. Note the project it belongs to.
4. Connect a supported coding tool like Claude Code or Cursor via Integrations. Ask it to read the project context and Skills at the start of each session.
5. Keep current tasks on the board. When a task involves implementing a new pattern, add the decision to Decisions and rules before you start, so the next session finds it there.

fenbs does not connect to Gemini directly over MCP. For Gemini sessions, copy the Skill text from fenbs and paste it into the Gem instructions. The ai-prompts topic hub has more guides on managing coding instructions across tools.

When a coding Gem is not the right tool

A Gemini Gem for coding works well for reviewing a function, explaining a pattern, or drafting a short piece of code you describe in the conversation. It does not have access to your local files, cannot run commands, and cannot make changes across multiple files at once.

For tasks that require file access or multi-file edits, a coding tool like Claude Code or Cursor is a better fit. Those tools connect to your local environment and can read the repository directly. You can still use your Gem instructions in those tools by saving them as Skills in fenbs and letting the connected app read them at session start.

A Gem is the right choice when you want a quick review or explanation in a chat interface and do not need the assistant to touch your files. Keep one Gem for code review discussions and use your coding tools for the actual edits. The two workflows complement each other rather than compete.