chore: Trim the shared cubic review instructions (#37492)

cubic.yaml

@@ -60,33 +60,29 @@ reviews:
   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.
+    Rank findings in this order: architecture fit, solution complexity, bugs and
+    behavioural regressions, security edge cases, code quality, missing tests.
+    Report style and naming last, and only when they 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.
+    Name the concrete failure: the input, state or sequence that makes the code
+    wrong. Then give the fix, a snippet or the function to call. "This could be
+    cleaner" is noise. Do not manufacture findings; zero comments on a clean PR is
+    a good review. Ask the intent when a deliberate decision and a mistake look
+    the same.
 
     ## 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.
+    Review only the lines this PR adds or modifies. Do not report problems that
+    already exist in the surrounding code. Each rule file names the packages it
+    covers; skip it when the changed code is out of scope, and say nothing when
+    none apply.
 
     ## 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.
+    `pnpm lint`, `pnpm typecheck`, Poutine, Zizmor and `@n8n/code-health` run on
+    every PR. A defect one of them fails the build for is not a finding; the
+    author sees it first. Rule files name the exemptions. Report what static
+    analysis cannot see.
 
     ## This is a public repository
 
@@ -97,9 +93,9 @@ reviews:
 
     ## 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.
+    For PRs from outside the n8n organisation, apply the "Community PR Guidelines"
+    section of `CONTRIBUTING.md`: a contribution should be worth more to the
+    project than the time it takes to review it.
   custom_rules:
     - name: Security
       file_paths: