n8n/cubic.yaml

# yaml-language-server: $schema=https://cubic.dev/schema/cubic-repository-config.schema.json

# cubic.yaml
# This file configures AI review behavior, ignore patterns, PR descriptions, and custom rules.
# Place this file in your repository root to version-control your AI review settings.
# Settings defined here take precedence over UI-configured settings.
# See https://docs.cubic.dev/configure/cubic-yaml for documentation.
#
# Guidance lives at one of three levels of reach: `custom_instructions` for what
# is true of every agent, a rule file linked by several agents for a policy that
# is identical across domains, and an agent's own directory for everything else.
# `.agents/review-rules/README.md` explains the split.
#
# Only the first 5 custom_rules take effect, and each one is truncated at 10,000
# characters — its description, its linked file_paths, and custom_instructions,
# which is prepended to every agent and so is charged against each one separately.
# `pnpm check:cubic-config` enforces both limits and prints the split.
# Scope every rule with include/exclude so it is not evaluated against the whole monorepo.

version: 1
reviews:
  enabled: true
  sensitivity: medium
  incremental_commits: true
  check_drafts: true
  architecture_diagrams: false
  merge_confidence_summary: true

  # Both of these turn on a risk judgement this config deliberately does not
  # define — guessing the scale up front would just bake in a wrong one. Shadow
  # mode makes a miscalibrated call free, so calibrate from what cubic actually
  # classifies before writing a risk section into custom_instructions.
  auto_approve_behavior: shadow
  auto_approve: low_risk_only

  auto_ultrareview: high_risk_only

  ignore:
    # Mechanical PRs: content was already reviewed on master, or there is nothing
    # to review. Backports stay reviewed — their conflicts are resolved by hand.
    pr_labels:
      - automation:v3-sync
      - automation:release
      - automation:scheduled-update
    # Above this, cubic skips the automatic review; `@cubic-dev-ai review this`
    # still works. CI already caps PRs at 1000 lines, so crossing this is always
    # a deliberate exception. Makes explicit a limit cubic otherwise applies on
    # its own terms.
    max_changed_lines: 10000
    files:
      - CHANGELOG.md
      - pnpm-lock.yaml
      - '**/dist/**'
      - '**/__snapshots__/**'
      - '**/*.snap'
      - '**/*.generated.yml'
      - '**/*.generated.ts'
  # Reaches every agent, so it holds only how to review — never what to look
  # for. Domain rules belong in a rule file under `.agents/review-rules/`.
  custom_instructions: |-
    ## The bar for a comment

    Priority order: architecture fit, solution complexity, bugs and behavioural
    regressions, security edge cases, code quality, missing tests. Style and
    naming last, and only when they genuinely matter.

    A comment must name the concrete failure — the input, state, or sequence that
    makes the code wrong — and what to do instead: the snippet, or the specific
    function to reach for. "This could be cleaner" is noise. Zero comments on a
    clean PR is a good review; do not manufacture findings.

    Where a deliberate decision and a mistake look identical, ask what the intent
    was rather than asserting a defect.

    ## Scope

    Review only the lines this PR adds or modifies. Each PR is meant to have a
    limited scope — do not report problems in surrounding code that already
    existed.

    Each linked rule file opens with the packages it applies to. Skip a file when
    the changed code is out of its scope; if none apply, say nothing.

    ## Don't repeat what CI already fails on

    `pnpm lint`, `pnpm typecheck`, Poutine, Zizmor, and `@n8n/code-health` run on
    every PR. A defect one of them already fails the build for is not a finding —
    the author sees it before you do. The linked rule files name the specific
    exemptions. Report what static analysis cannot see.

    ## This is a public repository

    Your comments are public. On a change that looks security-related, describe the
    defect in functional terms — do not spell out an exploit path, name a
    vulnerability class, or speculate about attacks in the thread. Never name a
    customer; say "a customer" or "a large deployment" instead.

    ## Community contributions

    For PRs from outside the n8n organisation, the bar is set by the "Community PR
    Guidelines" section of `CONTRIBUTING.md`. The golden rule there: a contribution
    should be worth more to the project than the time it takes to review it.
  custom_rules:
    - name: Security
      file_paths:
        - .agents/review-rules/security/code-execution-and-sandboxing.md
        - .agents/review-rules/security/credentials-and-secrets.md
        - .agents/review-rules/security/auth-and-access-control.md
        - .agents/review-rules/security/data-and-infrastructure.md
        - .agents/review-rules/security/node-input-safety.md
      include:
        - packages/cli/**
        - packages/@n8n/db/**
        - packages/core/**
        - packages/workflow/**
        - packages/nodes-base/**
        - packages/@n8n/nodes-langchain/**
      exclude:
        - '**/__tests__/**'
        - '**/*.test.ts'
        - '**/*.spec.ts'
        - '**/test/**'
      description: |-
        Flag security defects introduced by this PR, using the linked rules.

        Higher scrutiny for the expression engine, credential handling, code
        execution nodes, license enforcement, and SSO integrations. Community
        and custom nodes carry a higher risk profile than official ones.
    - name: Backend
      file_paths:
        - .agents/review-rules/backend/controller-request-validation.md
        - .agents/review-rules/backend/error-classes.md
        - .agents/review-rules/backend/explicit-any.md
        - .agents/review-rules/backend/lazy-load-heavy-modules.md
        - .agents/review-rules/backend/hand-rolled-delays.md
        - .agents/review-rules/testing/coverage.md
      include:
        - packages/cli/**
        - packages/@n8n/db/**
        - packages/core/**
        - packages/workflow/**
        - packages/nodes-base/**
        - packages/@n8n/nodes-langchain/**
      exclude:
        - '**/__tests__/**'
        - '**/*.test.ts'
        - '**/*.spec.ts'
        - '**/test/**'
      description: |-
        Review n8n's backend and node packages against the linked rules. Think in
        terms of blast radius, resource cost, and failure modes.

        The rules are drawn from real incidents and the conventions the team
        enforces.

        ESLint already fails the build for `@n8n/typeorm` imports in
        `packages/cli` business logic, uncaught `JSON.parse`, and
        `JSON.parse(JSON.stringify())` — never spend a comment on those.
    - name: Frontend
      file_paths:
        - .agents/skills/design-system/SKILL.md
        - .agents/review-rules/frontend/design-system.md
        - .agents/review-rules/frontend/workflow-document-store.md
        - .agents/review-rules/testing/coverage.md
      include:
        - packages/frontend/**
      exclude:
        - '**/__tests__/**'
        - '**/*.stories.ts'
        - '**/*.spec.ts'
      description: |-
        Enforce n8n's frontend conventions using the linked rules. The design
        system skill is the source of truth for which token to reach for; the
        rule files that follow set the enforcement level.
    - name: QA & DX
      file_paths:
        - .agents/review-rules/qa-dx/docker-native-modules.md
        - .agents/review-rules/qa-dx/docker-image-pinning.md
        - .agents/review-rules/qa-dx/workflow-safety.md
        - .agents/review-rules/qa-dx/ratchets-and-allowlists.md
      include:
        - .github/**
        - docker/**
        - scripts/**
        - patches/**
        - packages/testing/**
        - packages/@n8n/eslint-config/**
        - packages/@n8n/stylelint-config/**
        - packages/@n8n/vitest-config/**
        - packages/@n8n/typescript-config/**
        - '**/eslint.config.mjs'
        - '**/vitest.config.*'
        - '**/turbo.json'
        - .poutine.yml
        - codecov.yml
        - .code-health-baseline.json
        - .boundaries-baseline.json
        - '**/.janitor-baseline.json'
      description: |-
        Review the build, test, and CI surface against the linked rules. These
        are lessons from builds that actually broke and from checks that turned
        out to be bypassable, not general Docker or Actions advice.

        What this surface's scanners cannot see: a documented invariant being
        undone, a guard being widened, a gate that stops being able to fail.

  # cubic silently drops any rule past the fifth, so the last slot is a decision,
  # not somewhere to append. Merge into an existing agent instead.
pr_descriptions:
  generate: false
issues:
  fix_with_cubic_buttons: true