AGENTS.md in Gemini CLI: Support and Shared Instructions

AGENTS.md is a convention adopted by several AI coding tools for storing project-level instructions that the tool reads automatically at the start of a session. Gemini CLI's native instruction file is GEMINI.md, not AGENTS.md. If you want consistent project rules across Gemini CLI and other tools that do read AGENTS.md, you need a deliberate setup. Tools like fenbs handle the dynamic project context that no static file can keep current: tasks, decisions, lessons and where the team left off.

Knowing which file Gemini CLI reads, and what it does with it, prevents writing instructions into the wrong place and wondering why they have no effect.

How Gemini CLI reads project instructions

Gemini CLI looks for a GEMINI.md file in the project directory. Instructions in that file are included in the context when you start a session in that directory. The file follows Markdown conventions and can include project-specific rules, conventions and context that should apply to every session in that codebase.

To check whether your version of Gemini CLI supports GEMINI.md and how it handles nested or global instruction files, open the Gemini CLI documentation at the Google DeepMind GitHub repository or the Google AI developer docs. The specific behavior, including which directories are checked and in what order, may change between versions.

After you install and configure Gemini CLI, see how to install Gemini CLI for the setup steps, and Gemini CLI best practices for the conventions the community has settled on.

Does Gemini CLI support AGENTS.md?

Gemini CLI does not natively read AGENTS.md as of the current documentation. The AGENTS.md convention was established by tools like Claude Code, which reads AGENTS.md natively, and has since been adopted by other coding agents. Gemini CLI chose GEMINI.md as its equivalent.

If you maintain both an AGENTS.md and a GEMINI.md in the same repository, they can contain the same core rules, but you are maintaining two files. One approach is to keep the canonical rules in a single source, such as a shared project record, and generate or reference them in each tool's instruction file. Another is to keep GEMINI.md short and point to fenbs for the rules that matter most.

For a comparison of Gemini CLI with a tool that does read AGENTS.md natively, see Gemini CLI vs Claude Code. For how to use Gemini CLI in VS Code, see Gemini CLI in VS Code.

What to put in your GEMINI.md

A GEMINI.md file is most useful for facts that are stable and do not change session to session:

• The project's language, framework and build system.
• Naming conventions and code style rules.
• Which directories contain source code, tests and configuration.
• Standing constraints: for example, "do not modify the database schema directly."
• A pointer to where the live project context lives: "Before starting, read the project AI context in fenbs."

Keep the file short. A long GEMINI.md that mixes stable rules with current task status or decisions becomes stale quickly, because task status changes and decisions get superseded. Static facts in the file; live context in fenbs.

For examples of well-structured instruction files, see AGENTS.md examples for the patterns that work well across tools, noting that the filename differs for Gemini CLI.

Using fenbs for live project context

A static instruction file cannot answer "what is the team working on right now?" or "what rule did we agree on last Tuesday?" Those answers live in a shared project record that is updated as the work progresses. fenbs holds that record and makes it available to Gemini CLI through an MCP connection, just as it does for Claude, Cursor and the other supported tools.

At the start of a session with Gemini CLI, you can instruct the assistant to connect to fenbs via MCP and read the project AI context before starting work. The context includes Decisions and rules, Where we left off, and In progress tasks, which together give the same starting point that the GEMINI.md file cannot provide on its own.

How to do this with fenbs

1. Create a free account and add your project in fenbs.
2. Create a GEMINI.md in your project root with stable conventions: language, framework, naming rules, standing constraints.
3. Add a line at the bottom of GEMINI.md pointing to the fenbs context: "Before starting work, connect to fenbs and read the project AI context."
4. Connect Gemini CLI from Integrations using the MCP connection steps for that tool.
5. In Decisions and rules in fenbs, write the rules that should apply to every session. Keep GEMINI.md for the static facts; update the fenbs record as the project evolves.

For teams using multiple tools alongside Gemini CLI, for example Gemini CLI vs Gemini Code Assist covers the differences, fenbs provides one shared record that all of them can read and update. A rule added to fenbs applies to every connected tool, not just the one whose instruction file you last updated.