Contribute a Gemini Code Assist config

[devoncarew]

Contribute a Gemini Code Assist config:

• contribute a Gemini Code Assist config (docs at https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github)
• disable the initial PR summary
• keep the code review comment on PR open
• keep the 'comment severity' at medium; we should consider increasing to high based on the reviews we see
• contribute a brief style guide; mention Effective Dart and the 3-4 things we already say on each PR

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[gemini-code-assist]

Hello @devoncarew, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

I am currently reviewing this pull request. In the meanwhile, I am providing a summary of the content of the pull request for you and other reviewers to get up to speed quickly on the changes that have occurred, and the intent behind these changes.

This pull request contributes a Gemini Code Assist configuration file and a style guide for the dart-lang repository. The configuration disables the initial PR summary from the bot, keeps the code review comment on PR open, and sets the comment severity threshold to medium. The style guide provides a brief overview of coding conventions, referencing Effective Dart and highlighting key points already observed in previous PRs.

Highlights

• Gemini Code Assist Configuration: Adds a .gemini/config.yaml file to configure the Gemini Code Assist bot's behavior, disabling the initial PR summary and setting the comment severity threshold.
• Style Guide: Adds a .gemini/styleguide.md file providing a brief style guide for Dart code contributions, referencing Effective Dart and highlighting key contribution guidelines.
• Configuration Changes: The Gemini Code Assist configuration disables the initial PR summary to reduce noise and keeps the code review comment open for ongoing discussions.

Changelog

• .gemini/config.yaml
  • Added a configuration file for the Gemini Code Assist bot.
  • Disabled the initial PR summary.
  • Kept the code review comment on PR open.
  • Set the comment severity threshold to MEDIUM.
• .gemini/styleguide.md
  • Added a brief style guide for Dart code contributions.
  • Referenced Effective Dart style guide.
  • Highlighted key contribution guidelines, including discussing significant changes in an issue before creating a PR, following the Dart style guide, adding changelog entries, and including corresponding tests.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

A config file, neat and trim,
Sets Gemini's behavior on a whim.
No summaries grand,
Just reviews at hand,
A style guide to keep code in line, within.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request introduces a Gemini Code Assist configuration and a basic style guide. The changes look good overall. I've added a few suggestions to improve clarity and consistency.

Summary of Findings

• Clarity in YAML comments: The comments in the .gemini/config.yaml file could be more descriptive to explain the purpose of each configuration option.
• Style guide link: The style guide link in .gemini/styleguide.md could be improved to directly link to the style guide section of the Effective Dart guide.

Assessment

The pull request introduces a Gemini Code Assist configuration and a basic style guide for the dart-lang repository. The configuration disables the initial PR summary and keeps the code review comments open, while the style guide refers to the Effective Dart style guide. Overall, the changes seem reasonable and align with the stated goals. I've provided some minor feedback to improve clarity and consistency. I would recommend addressing these comments before requesting a review from someone else, but feel free to request another review from Gemini via /gemini review when you have addressed these comments and I'll take another look! Note that I am not authorized to directly approve the pull request, and users should have others review and approve this code before merging.

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

File	Coverage

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[parlough]

Do I need to add a config per repo or there is a way to share a config in the .github repo?

[devoncarew]

Do I need to add a config per repo or there is a way to share a config in the .github repo?

The docs I'm going from are https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github. They don't mention anything about looking at the .github repo as a fallback; though that would definitely be a nice feature. Absent that, I'd like to dial in a config we're happy w/ here and the replicate it across the repos.

[gemini-code-assist]

That's a great question, parlough! As devoncarew mentioned, the current implementation doesn't support a shared config in the .github repo. It would be a nice feature to have, though. For now, replicating the config across repos seems like the best approach. Perhaps we can explore the possibility of a shared config in the future.

[natebosch]

😆