GEMINI.md for the Gemini CLI
How to write GEMINI.md so the Gemini CLI builds and tests your project the way the repo expects.
Project context, not a chat prompt
The Gemini CLI reads GEMINI.md from the repository root the way Claude Code reads CLAUDE.md. Put standing rules there: language, framework, commands, and the boundaries you do not want crossed.
A pasted system prompt dies with the chat. GEMINI.md stays in git. That is the right place for 'this is a Spring Boot service, use the Maven wrapper, do not bind requests onto entities.'
Make the first paragraph do the work
Gemini should be able to tell what kind of repository this is from the first lines. Then list commands. Then list the bans. If you also use Claude Code or Cursor, generate those files from the same stack so the commands do not diverge.
Do it in this order
01
Add GEMINI.md at the root
The CLI looks for that exact name.
02
State the stack in the first paragraph
Include the build tool and the test runner.
03
List bans
Secrets, thread rules, and the framework you are not using.
04
Start a new CLI session
An existing session will not reload the file.
Questions
Is GEMINI.md the same as AGENTS.md?
The advice can match. The filenames are loaded by different tools. Commit the one your team actually runs.
Can I nest GEMINI.md?
Keep the root file complete. Add a nested file only when one directory has extra rules, and do not contradict the root.