Optibot Config

Getting started with the Optibot Configuration Settings

Customize how Optibot behaves across your repositories directly from the Optibot dashboard. Each repository gets its own configuration. Toggle features on or off, set review triggers, manage exclusions, and more. Changes take effect immediately with no files to commit or maintain. Access your settings at: agents.getoptimal.ai → Configuration tab Reviews Control when and how Optibot reviews pull requests on this repository. - Auto review — Automatically review every PR on open. (Recommended) - Auto review on draft — Include draft PRs in automatic reviews. - Auto review on push — Trigger a new review whenever commits are pushed to an open PR. - Auto review after workflow — Trigger a review only after a CI workflow completes. Useful if you want reviews to run post-build rather than immediately on open. - Allow approve — Allow Optibot to approve PRs that pass all checks. - Code suggestions — Allow Optibot to generate inline code suggestions during reviews when needed. - Skip files — Files or patterns that should be excluded from the review process (e.g. *.md, docs/*). - Sensitivity — Controls the strictness of the review. Low, Medium, or High. Medium is recommended for most teams. - Excluded labels — PRs carrying any of these labels are skipped for automatic reviews (e.g. wontfix). - Excluded users — PRs authored by these usernames are skipped for automatic reviews (e.g. bot-account). - Suppress repeated issues — When enabled, issues already raised in a previous review are moved to a collapsible section instead of being posted as new inline comments. Summary Control when and how Optibot generates PR summaries. - Auto summary — Automatically generate a PR summary on open. - Auto summary on draft — Include draft PRs in automatic summaries. - Summary level — Controls the detail level of generated summaries. Basic or Detailed. - Excluded labels — PRs with these labels are skipped for automatic summaries. - Excluded users — PRs from these usernames are skipped for automatic summaries. Dependency Bundler - Enabled — Organizes and bundles incoming Dependabot PRs into a single consolidated PR. Reduces noise from individual dependency update PRs. Other Settings - Enable CI fixer — Attempts to fix failed CI checks by opening fix PRs and/or suggesting remediation steps. - Tag to talk — When enabled, Optibot will only respond to comments that contain the tag @optibot. Useful for teams who want manual control over when Optibot engages. - Guidelines URL — Path or URL pointing to your coding guidelines file inside the repository (e.g. docs/guidelines/README.md). Optibot uses this for context-aware enforcement during reviews. You can also edit or generate guidelines from the Repository Guidelines page. Review Fixer - Enable Review Fixer — Allow Optibot to automatically apply review comment fixes directly to your code when accepted. Note: Settings are per-repository. If you manage multiple repositories, you'll need to configure each one separately from the repository selector in the Settings tab.

Configuration Parameters for Optibot — Reviews

Configuration options for code reviews The Reviews settings control automated code review functionality per repository. Access them from your Optibot dashboard at agents.getoptimal.ai → select a repository → Settings tab → Reviews section. All settings can be toggled from the form view or edited directly in the raw JSON panel. Auto Review on PR Creation Setting: Auto review Type: boolean Default: Off Controls whether Optibot automatically reviews pull/merge requests when they are created. When to use: Turn on if you want immediate feedback on all pull requests when they are first opened. Optibot will generate a full context-aware code review of your changes. Turn off if you prefer to manually trigger reviews — you can always do this by typing Optibot can you review this in any PR or MR comment on GitHub or GitLab. Auto Review on New Commits Setting: Auto review on push Type: boolean Default: Off Configures Optibot to automatically re-review a pull or merge request every time new commits are pushed. Gives you continuous feedback as you iterate on a PR without needing to manually request another review. When to use: - Ideal when you push multiple follow-up commits to address feedback - Ensures each update is automatically re-reviewed - Removes the need to manually trigger additional reviews - Helps teams maintain high-quality, iterative review workflows Auto Review After CI Workflow Setting: Auto review after workflow Type: boolean Default: Off Triggers a review only after a CI workflow completes rather than immediately on PR open. Useful if you want Optibot to review post-build, once you know the branch is in a stable state. Automated PR Approvals Setting: Allow approve Type: boolean Default: Off Gives Optibot the ability to automatically approve pull/merge requests that pass its review criteria. When to use: - For trusted contributors or automated dependency updates - When you have strict CI/CD checks and trust Optibot's judgment - When you regularly push atomic, small-to-medium PRs - When you require multiple approvals to merge — Optibot's approval can count as one ⚠️ Use carefully. This gives Optibot approval authority. Best combined with Excluded Labels or Excluded Users to maintain controlled auto-approval. Consider your team's review policies before enabling. Recommended setup when using Allow Approve: Enable Auto Review, enable Allow Approve, and add excluded labels like needs-review and breaking-change, and excluded users for any junior engineers whose PRs should always require human review. Code Suggestions Setting: Code suggestions Type: boolean Default: On Allows Optibot to generate inline code suggestions and improvements during reviews. Suggestions appear as committable changes or code change recommendations directly in the PR. When to use: - Keep on for actionable, specific code improvement suggestions - Turn off if you only want high-level feedback without specific code changes — useful if your team has an internal mandate against AI-generated code suggestions, or if you're working to reduce engineer dependency on AI-generated fixes Skip Files Setting: Skip files Type: array of glob patterns Default: Empty Tells Optibot to skip reviewing certain files based on glob patterns. Optibot will not generate suggestions on matching files and will not read them during a review. When to use: - Exclude auto-generated files, test files, or documentation - Focus reviews on production code only and ignore compiled or built output - Skip files that change frequently or follow different conventions - Skip files with legal requirements against AI-generated code (some regulated industries require specific files to only be edited and maintained by humans) Pattern examples: Skip test files and documentation: *.test.js, *.test.ts, *.md, docs/**/* Skip generated and configuration files: *.generated.*, dist/**/*, build/**/*, *.config.js, package-lock.json Skip vendor and third-party code: vendor/**/*, node_modules/**/*, third_party/**/* Glob pattern reference: - *.ext — files with that extension in the repo root only - **/*.ext — files with that extension in any directory (recursive) - dir/**/* — all files under a specific directory - *.test.* — files with .test. in the name, repo root only Review Sensitivity Setting: Sensitivity Type: string — Low / Medium / High Default: Medium Controls how aggressively Optibot flags issues in your code. - Low — Only reports high-confidence, critical issues such as bugs and security vulnerabilities. Best for teams that want a minimal, signal-only review with no noise. - Medium — The default. Balances critical findings with important improvements — covers bugs, security, and error handling without being overwhelming. Recommended for most teams. - High — Reports everything, including minor issues, stylistic concerns, and suggestions. Best for teams that want thorough, comprehensive feedback on every PR. When to use: - Use Low if your team is getting too many comments and wants Optibot to focus only on what matters most - Use Medium for a balanced review experience (recommended) - Use High if you want maximum coverage and are comfortable triaging more comments per PR Excluded Labels Setting: Excluded labels Type: array of strings Default: Empty Prevents Optibot from reviewing PRs or MRs that carry any of the specified labels. Labels are case-sensitive and must be an exact match. When to use: - Skip reviews for work-in-progress changes - Skip auto-generated PRs from tools like Dependabot, Snyk, or SonarQube - Exclude draft or experimental branches - Bypass reviews for hotfixes or emergency changes Examples: Skip WIP and draft PRs: WIP, work-in-progress, draft Emergency bypass: hotfix, emergency, critical-fix Exclude documentation-only changes: documentation, docs-only, readme-update Note: Use exact label names as they appear in GitHub or GitLab — both platforms are case-sensitive. Excluded Users Setting: Excluded users Type: array of strings Default: Empty Prevents Optibot from reviewing PRs or MRs opened by specified usernames. When a matching user opens a PR, Optibot will not review it even if Auto Review is on. When to use: - Exclude dependency bots (Dependabot, Renovate) - Skip reviews for CI/CD and release automation accounts - Bypass automated deployment accounts Examples: Exclude dependency bots: dependabot, renovate, renovate[bot] Exclude CI/CD bots: github-actions[bot], gitlab-ci, release-bot, deployment-bot Note: Use the exact username as it appears on GitHub or GitLab, including any [bot] suffix where applicable. Auto Review on Draft Setting: Auto review on draft Type: boolean Default: Off When turned on, Optibot will review pull or merge requests that are in draft state. By default, Optibot skips draft PRs and only reviews once the PR is marked "Ready to review" on GitHub (or equivalent on GitLab). When to use: Turn on when you want Optibot to continuously review work-in-progress PRs as you build — useful for catching issues early before the PR is ready for human review. Suppress Repeated Issues Setting: Suppress repeated issues Type: boolean Default: Off When enabled, issues that were already raised in a previous review on the same PR are moved to a collapsible section instead of being posted again as new inline comments. Reduces noise on PRs with multiple review cycles. Note: All settings are per-repository. Configure each connected repository separately from the repository selector at the top of the Settings tab. Changes take effect immediately for new PRs and MRs — no commits or deployments required.

Optibot configuration for Summaries

Summary Configuration The Summary settings control automated PR and MR summary generation per repository. Access them from your Optibot dashboard at agents.getoptimal.ai → configuration tab → Summary section. Toggle settings from the form view or edit directly in the raw JSON panel. Auto Summary Setting: Auto summary Type: boolean Default: On Enables or disables automatic summary generation when a new PR or MR is opened. Optibot summaries cover the functional aspects of the code changes in detail, plus a collapsible file-by-file breakdown. When to use: - Keep on for automatic summaries on all PRs — helps reviewers understand changes at a glance and can often replace the need to write a PR description manually - Turn off if summaries should only be generated on request, or if you have specific PR description requirements that summaries would conflict with Auto Summary on Draft Setting: Auto summary on draft Type: boolean Default: On Controls whether Optibot generates summaries on PRs and MRs that are in draft state. By default, Optibot will summarize draft PRs when they are opened. Turn this off if you want Optibot to wait until the PR is marked "Ready to review" on GitHub (or equivalent on GitLab) before generating a summary. When to use: Turn off when your draft PRs are genuinely work-in-progress and you expect to push more changes before anyone should be reviewing or reading a summary. Summary Level Setting: Summary level Type: string — Short / Basic / Detailed Default: Basic Controls the depth of detail Optibot includes in generated summaries. Short A concise 2–3 sentence natural-language overview of the pull request. Ideal for quick updates that don't interrupt workflow, or when reviewers only need a high-level read. Example output: Updates login flow to streamline authentication and add basic validation. Cleans up unused logic and prepares the service for upcoming enhancements. Basic A brief overview of changes, key modifications, and an impact summary. Works well for small, atomic PRs that require quick reviews. Example output: This PR adds user authentication middleware and updates the login endpoint. Key Changes: 2 new files, 3 modified files, ~150 lines changed. Detailed A comprehensive analysis with file-by-file breakdown, architectural impact notes, and testing recommendations. Best for large PRs, complex features, and critical changes. Example output: This PR implements JWT-based authentication middleware with refresh token support. Files Changed: - src/middleware/auth.ts (new): JWT verification middleware with role-based access control - src/routes/auth.ts (modified): Added refresh token endpoint - src/utils/token.ts (new): Token generation and validation utilities Impact Analysis: - Security: Implements industry-standard JWT authentication - Performance: Adds ~10ms latency per authenticated request - Testing: Requires new integration tests for auth flows - Dependencies: Added [email protected] and [email protected] When to use: - Use Short for fast-moving teams or when summaries are supplementary to existing PR descriptions - Use Basic for most teams — the right balance of context without overwhelming reviewers - Use Detailed for large codebases, complex features, or any PR where architectural context matters Excluded Labels Setting: Excluded labels Type: array of strings Default: Empty Prevents Optibot from generating summaries on PRs or MRs that carry any of the specified labels. Labels are case-sensitive and must be an exact match. When to use: - Skip summaries for trivial or minor changes - Exclude documentation-only PRs - Bypass summaries for automated dependency updates Examples: Skip trivial changes: trivial, typo-fix, formatting Exclude docs and dependencies: documentation, dependencies Note: Use exact label names as they appear in GitHub or GitLab — both are case-sensitive. Excluded Users Setting: Excluded users Type: array of strings Default: Empty Prevents Optibot from generating summaries on PRs or MRs opened by specified usernames. Especially useful when bot accounts regularly open automated PRs that don't need a summary. When to use: - Exclude bot accounts that create automated PRs (Dependabot, Renovate, localization bots) - Skip summaries for specific team members if needed Examples: Exclude common bots: dependabot, renovate[bot], l10n-bot Note: Use the exact username as it appears on GitHub or GitLab, including any [bot] suffix where applicable. Note: All settings are per-repository. Configure each connected repository separately from the repository selector at the top of the Settings tab. Changes take effect immediately for new PRs and MRs — no commits or deployments required.

Optibot configuration for auto CI fixes

Optibot CI Fixer The CI Fixer setting controls automated CI/CD pipeline failure detection and fixes. Access it from your Optibot dashboard at agents.getoptimal.ai → Configuration tab → Other Settings section. ⚠️ GitHub only. The CI Fixer works with GitHub Actions. It is not available for GitLab repositories. Enable CI Fixer Setting: Enable CI fixer Type: boolean Default: Off When turned on, Optibot monitors your GitHub Actions workflows. If any CI check fails, Optibot intercepts the error, analyzes the root cause, works through a solution, and opens a new draft PR with the fix along with a detailed explanation of what it changed and why. When to use: - Enable for projects with complex CI/CD pipelines where failures are common - Useful for catching and resolving pipeline issues automatically without pulling an engineer away from their current work - Helps reduce the time spent manually reading CI logs and debugging failures What the CI Fixer Does When a GitHub Actions workflow fails on an open PR, Optibot: 1. Detects the failed workflow run 2. Reads the error logs and identifies the affected files 3. Analyzes the root cause of the failure 4. Applies targeted fixes and opens a new draft PR with the changes 5. Posts a comment on the original PR summarizing the issue, what was changed, and why Engineers review the draft fix PR, merge it if it looks correct, and the original PR build goes green — without anyone having to manually triage the CI log. Common Issues the CI Fixer Can Resolve - Missing or incorrect environment variables - Incorrect GitHub Actions workflow syntax - Dependency installation failures - Test configuration issues - Build script errors - Type errors and syntax issues in source files causing workflow failures Requirements - GitHub Actions must be enabled on the repository - The repository must be connected to Optibot via the GitHub integration - Optibot must have read/write permissions on checks and pull requests (granted during GitHub App installation) GitLab Users This feature is not available for GitLab repositories. The CI Fixer is specific to GitHub Actions. If you are on GitLab, leave this setting off — it will have no effect on GitLab workflows. Note: Settings are per-repository. Configure each connected repository separately from the repository selector at the top of the Settings tab. Changes take effect immediately — the CI Fixer will begin monitoring new workflow runs as soon as it is turned on.

Optibot configuration for dependency management

Enabling the optibot dependency bundler The Dependency Bundler setting controls automated consolidation of Dependabot pull requests. Access it from your Optibot dashboard at agents.getoptimal.ai → Configuration tab → Dependency Bundler section. ⚠️ GitHub only. The Dependency Bundler requires Dependabot and works with GitHub repositories only. It is not available for GitLab. Enable Dependency Bundler Setting: Enabled Type: boolean Default: Off When turned on, Optibot analyzes your pending Dependabot PRs and consolidates compatible updates into a single PR. Instead of reviewing and merging dozens of individual dependency update PRs, your team gets one clean PR with a summary of what changed and any breaking updates flagged separately. When to use: - Enable for projects with frequent dependency updates where Dependabot generates high PR volume - Useful for teams who want to reduce the noise and overhead of managing individual dependency PRs one by one - Helps keep your dependency management process from becoming a bottleneck What the Dependency Bundler Does When enabled, Optibot: 1. Monitors pending Dependabot PRs on the repository 2. Analyzes which updates are compatible and safe to bundle together 3. Consolidates compatible updates into a single PR with a clean summary of all changes 4. Flags any breaking changes or updates that should be reviewed and merged separately 5. Reduces the number of open dependency PRs your team needs to manage at any given time Requirements - Dependabot must be enabled on the repository - The repository must be connected to Optibot via the GitHub integration - Optibot must have read/write permissions on pull requests (granted during GitHub App installation) GitLab Users This feature is not available for GitLab repositories. The Dependency Bundler is specific to GitHub and requires Dependabot. If you are on GitLab, leave this setting off — it will have no effect. Note: Settings are per-repository. Configure each connected repository separately from the repository selector at the top of the Settings tab. Changes take effect immediately once enabled — Optibot will begin analyzing pending Dependabot PRs on the next cycle.