Team Configurations & Shared Workflows

Scaling Gemini CLI across a team requires three shared artifacts: a project GEMINI.md (checked into git), a .gemini/settings.json (project-level MCP servers and tool configuration), and a .gemini/commands/ directory (team slash commands). These three files are version-controlled, code-reviewed, and maintained like any other codebase artifact. When a new developer clones the repo, they inherit the team's AI configuration automatically.

The separation between project-scoped and user-scoped configuration is critical for teams. Project scope (.gemini/ directory) holds team standards — the GEMINI.md rules, the MCP servers everyone needs, the review commands everyone uses. User scope (~/.gemini/) holds personal preferences — response verbosity, preferred language, personal MCP servers, custom formatting. Never put personal preferences in project scope. Never put team standards in user scope.

PROJECT SCOPE (checked into git, shared with team)
├── GEMINI.md                    → Architecture, conventions, standards
├── .gemini/
│   ├── settings.json            → MCP servers, tool filtering, model config
│   └── commands/
│       ├── review.toml           → Code review workflow
│       ├── test-plan.toml        → Test plan generation
│       ├── deploy-check.toml     → Pre-deployment validation
│       └── git-commit.toml       → Commit message generation
└── .geminiignore                → Files to exclude from context

USER SCOPE (personal, not in git)
├── ~/.gemini/
│   ├── GEMINI.md                → Personal preferences (verbosity, style)
│   ├── settings.json            → Personal MCP servers, global model preference
│   └── commands/
│       └── personal-notes.toml  → Personal productivity commands

1. Bootstrap project configuration Run /init to generate GEMINI.md. Create .gemini/settings.json with project MCP servers. Create .geminiignore. Commit all three.
2. Build team commands Identify your team's most common workflows. Create .toml commands for each. Start with code review and commit messages — these have the highest daily impact.
3. Document the setup Add a section to your project README explaining the Gemini CLI setup. Include setup steps for new developers: install, authenticate, verify with /tools.
4. Iterate via code review Treat GEMINI.md and .gemini/ changes like code changes. Review them in PRs. Discuss whether new rules, commands, and tool configurations serve the team.