default-kodus-config.yml

version: 2.0

# general
automatedReviewActive: true
showStatusFeedback: true
kodusConfigFileOverridesWebPreferences: false
reviewCadence:
    type: 'automatic' # automatic | auto_pause | manual
    timeWindow: 15 # minutes
    pushesToTrigger: 3
pullRequestApprovalActive: false
isRequestChangesActive: false # not on gitlab
runOnDraft: true
ignorePaths:
    - 'yarn.lock'
    - 'package-lock.json'
    - 'package.json'
    - '.env'
    - '**/*.json'
ignoredTitleKeywords: []
baseBranches: []
enableCommittableSuggestions: true
crossFileDependenciesAnalysis: true

# review categories
codeReviewVersion: 'v2' # legacy | v2
reviewOptions:
    # v2 / legacy
    bug: true
    performance: true
    security: true
    cross_file: true
    business_logic: true

# suggestion control
suggestionControl:
    groupingMode: 'full' # minimal | full
    applyFiltersToKodyRules: false
    limitationType: 'pr' # file | pr | severity
    maxSuggestions: 9 # min 7, no max
    severityLevelFilter: 'high' # low | medium | high | critical
    severityLimits: # when limitationType == severity
        low: 0
        medium: 0
        high: 0
        critical: 0

# PR summary
summary:
    generatePRSummary: true
    behaviourForNewCommits: 'none'
    behaviourForExistingDescription: 'replace'
    customInstructions: ''

# kody rules
ideRulesSyncEnabled: false
kodyRulesGeneratorEnabled: true
llmGeneratedMemoriesRequireApproval: false

# custom messages
customMessages:
    globalSettings:
        hideComments: false # github only
        suggestionCopyPrompt: true # not available for bitbucket

    startReviewMessage:
        status: 'every_push' # every_push | only_when_opened | off
        content: |
            # PR Summary (Comment created by [Kody](https://kodus.io) 🤖)

            ## Code Review Started! 🚀

            ✋ Hi, team! I'm already looking at the changed files and starting the review to ensure everything is in order. If you need more details, I'm here! [Kody](https://kodus.io)

            @reviewCadence

            @changedFiles

            @changeSummary

    endReviewMessage:
        status: 'every_push' # every_push | only_when_opened | off
        content: |
            ## Code Review Completed! 🔥

            The code review was successfully completed based on your current configurations.



            <details>
            <summary>Kody Guide: Usage and Configuration</summary>

            <details>
            <summary>Interacting with Kody</summary>

            - **Request a Review:** Ask Kody to review your PR manually by adding a comment with the \`@kody start-review\` command at the root of your PR.

            - **Provide Feedback:** Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

            </details>

            <details>
            <summary>Providing Context (Files & MCPs)</summary>

            Add these hints in your PR description (or a comment) to unlock deeper checks:

            - **Ticket / Acceptance Criteria:** \`Refs: ABC-123\` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
            - **Bugfix Validation:** a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
            - **Endpoint Risk:** mention the route (e.g., \`POST /api/payments\`) or controller/action name.
            - **Attach a repo file as context:** use an explicit marker like \`@file:docs/guide.mdx#L10-L50\` (replace with your real path).
            - **API Contract Docs:** include \`@file:openapi.yaml\` or \`@file:swagger.json\` when changing routes/schemas.
            - **Definition of Done / Standards:** include \`@file:DOD.md\` or \`@file:CONTRIBUTING.md\` if your repo has them.
            - **Design System Source of Truth:** include \`@file:ui/index.ts\` (replace with your DS entrypoint path).
            - **Feature Flags:** include the flag key/name and \`@file:flags.ts\` / \`@file:config.json\` (and optionally the PostHog flag name).
            - **Edge/CDN Rules:** link the Cloudflare rule/zone or describe the intended redirect/header behavior.
            - **Attach an MCP tool output:** use \`@mcp<provider|tool>\` (replace with an installed MCP provider + tool, e.g., \`@mcp<sentry|events.search>\`).

            </details>

            <details>
            <summary>Current Kody Configuration</summary>

            @reviewOptions

            </details>

            **[Access your configuration settings here.](https://app.kodus.io/settings/code-review/global/general)**

            </details>

# Prompt overrides
v2PromptOverrides:
    categories:
        descriptions:
            bug: |
                - Execution breaks: Code throws unhandled exceptions
                - Wrong results: Output doesn't match expected behavior
                - Resource leaks: Unclosed files, connections, memory accumulation
                - State corruption: Invalid object/data states
                - Logic errors: Control flow produces incorrect outcomes
                - Race conditions: Concurrent access causes inconsistent state or duplicates
                - Incorrect measurements: Metrics/timings that don't reflect actual operations
                - Invariant violations: Broken constraints (size limits, uniqueness, etc.)
                - Async timing bugs: Variables captured incorrectly in async closures
                - Conditional validation errors: Logic that checks for presence/absence of values using truthiness tests (e.g., `if dict.get("key")`) that fail with falsy values (0, None, False, ""), when membership tests (e.g., `if "key" in dict`) should be used
                - Dead computation: Code that computes/transforms values but never uses the result, instead using the original untransformed value - indicates copy-paste error or incomplete refactoring
                - Unbounded growth: Collections (lists, dicts, sets) that grow indefinitely within loops without size limits, potentially causing memory exhaustion
                - Duplicate operations: Same operation executed multiple times with identical inputs in sequence, wasting resources and potentially causing incorrect counts/metrics
            performance: |
                - Algorithm complexity: O(n²) when O(n) is possible
                - Redundant operations: Duplicate calculations, unnecessary loops, or early returns that force multiple operations when a single operation would suffice (e.g., fail-fast in batch processing that requires multiple requests to get complete feedback)
                - Memory waste: Large allocations or leaks over time
                - Blocking operations: Synchronous I/O in critical paths
                - Database inefficiency: N+1, missing indexes, full scans
                - Cache misses: Not leveraging available caching mechanisms
                - Batch processing inefficiency: Validation or processing loops that return on first error instead of collecting all errors, forcing clients to make multiple requests to discover all issues
            security: |
                - Injection vulnerabilities: SQL/NoSQL/command/LDAP injection
                - AuthZ/AuthN flaws: Missing checks, privilege escalation
                - Data exposure: Sensitive data in logs, responses, or errors
                - Crypto issues: Weak algorithms, hardcoded keys, improper validation
                - Input validation gaps: Missing sanitization or bounds checks
                - Session management: Predictable tokens or missing expiration
                - Timing attacks: Direct string/value comparison of secrets, tokens, passwords, or authentication credentials that leaks information through execution time - must use constant-time comparison functions
                - Insecure fallback values: Using empty strings, default values, or weak fallbacks for critical security parameters (encryption keys, secrets, tokens) when environment variables are missing - system should fail-fast instead
                - Input validation bypass: User-controlled parameters (offsets, limits, indices, IDs) accepted without validation or with inadequate bounds checking, especially negative values in array slicing or pagination that could bypass access controls
                - SSRF (Server-Side Request Forgery): Using user-controlled URLs in network operations (open, fetch, HTTP requests) without allowlist validation, enabling access to internal resources or arbitrary external sites
                - Case-sensitivity bypass: Inconsistent normalization in comparisons of case-insensitive data (emails, usernames, domains) where one side is normalized (toLowerCase/toUpperCase) but the other isn't, allowing bypass through case variations

    severity:
        flags:
            critical: |
                Application crash/downtime
                Data loss/corruption
                Security breach (unauthorized access/data exfiltration)
                Critical operation failure (auth/payment/authorization)
                Direct financial loss operations
                Memory leaks that inevitably crash production
            high: |
                Important functionality broken
                Memory leaks that cause eventual crash
                Performance degradation affecting UX under normal load
                Security issues with indirect exploitation paths
                Financial calculation errors affecting revenue
            medium: |
                Partially broken functionality
                Performance issues in specific scenarios
                Security weaknesses requiring specific conditions
                Incorrect but recoverable data
                Non-critical business logic errors with workarounds
            low: |
                Minor performance overhead
                Low-risk security improvements
                Incorrect metrics/logs
                Rarely affecting few users
                Edge-case issues

    generation:
        main: |
            Detailed and verifiable issue description
            - **No conversational filler**: Avoid phrases like "I noticed that," "It seems like," or "You should consider."
            - **Execute "Brevity First"**: Eliminate all introductory pleasantries. Start descriptions with the noun of the error (e.g., "Memory leak," "Null pointer dereference," "Timing attack").
            - **Direct addressing**: State the problem immediately, followed by the technical cause.
            - **Strictly technical**: Use only domain-specific terminology. If a bug is a race condition, start with "Race condition identified in..."
            - **Use Active Voice**: "The function leaks memory" instead of "Memory is leaked by the function."
            - **Sentence cap**: Limit the description to 1-2 high-impact sentences.