贡献流程与文档规范

官方贡献流程先讨论问题或功能，再提交聚焦的变更。代码和文档贡献都需要按项目要求签署 Contributor License Agreement，并遵守 Google 开源社区准则。

从议题开始

PR 应关联现有 issue：修复关联错误报告，功能关联经维护者认可的建议。官方说明缺少关联 issue 的 PR 可能被自动关闭，因此先建 issue 并等待反馈，再展开较大实现。

标有 🔒Maintainers only 的议题保留给维护者。可自行领取的议题需要满足官方的 help wanted 条件，且当前尚未分配；在评论中只写 /assign 或 /unassign 执行领取/释放。同一人最多自行分配 3 个议题。贡献页在不同段落使用 help-wanted 和 help wanted 的写法，实际标签以官方 issue 为准。

提交可审阅的变更

Fork 仓库后创建分支，在 packages 或 docs 中修改对应内容。一个 PR 聚焦一个问题或独立功能；尚需讨论的工作用 Draft PR 提供上下文。

提交前在 Gemini CLI 源码根运行：

npm run preflight

遵循当前 package.json 中定义的检查范围；集成测试和其他独立测试入口仍按相关文档执行，不把默认 unit test 当作全部验证。

PR 标题和描述应说明问题与改动原因，关联 issue；提交消息采用 Conventional Commits。所有提交，包括成员贡献，都需要代码审阅。

自动审阅辅助工具

官方脚本入口为：

./scripts/review.sh <PR_NUMBER> [model]

它会将 PR 检出到独立 worktree，安装依赖、构建并启动审阅工具。因此运行前需按官方要求确认待审 PR 代码可以安全执行。官方文档给出默认 Pro 与可选 Flash 示例，具体默认模型以当前脚本为准，不把示例模型当作长期固定值。

已经检出并构建时，可以在该源码环境的 CLI 中使用 /review-frontend <PR_NUMBER>。这是仓库提供的审阅命令，不是每个 Gemini CLI 安装都自带的通用 slash command。自动结果辅助人工审阅。

文档贡献

新增面向用户的行为需要同步更新 docs。官方文档目录由 docs/sidebar.json 组织，新增文件应放在正确目录并添加导航，检查相对链接目标。

官方风格要求标题用 sentence case、以第二人称说明操作、使用现在时、短段落和带语言标签的代码示例。分别可用 npm run lint、npm run format 和 npm run lint:fix 执行对应检查或修复；提交前再运行 preflight。

Fork 的 CI

Fork 默认需要在 GitHub Actions 页面启用工作流。涉及真实模型的集成测试需在自己的仓库配置有效 GEMINI_API_KEY secret；官方仓库的 secret 不会自动复制到 Fork。配置 CI 时确认测试会使用哪一个账号与额度。