Configuration File¶
Overview¶
CloudAEye's repository settings live in two markdown files you place in your repository:
| File | Holds |
|---|---|
.cloudaeye.config |
Settings: which checks ultrareview runs, its hard limits, human review policy, the review's severity floor, its LLM and your own LLM key, paths never reviewed, control flow, triage |
.cloudaeye.rules |
Review rules in plain words. See Rules and Instructions |
The CloudAEye commands in your coding agent read them. A setting placed in a file overrides the console settings; a setting no file names follows the console settings. Pull request reviews by the CloudAEye GitHub App use the console settings only; see the Overview.
The Default File¶
Paste this into .cloudaeye.config at the root of your repository, or download it. Every setting
is commented out, with its options beside it, so the file placed as it is changes nothing. For
each setting you want, remove the <!-- and --> around its line and set its value.
| File | Download |
|---|---|
.cloudaeye.config |
cloudaeye.config |
.cloudaeye.rules |
cloudaeye.rules |
Save a downloaded file with its leading dot: .cloudaeye.config, .cloudaeye.rules.
# CloudAEye settings
<!-- A setting inside comment marks is not read. To change one, remove the marks around its
line, or run /cloudaeye:config. The comment after a setting lists its options.
This file covers its own directory and everything below it. A .cloudaeye.config further
down wins over it, setting by setting. When a change touches files under different
settings, it gets whichever asks for more review.
A setting placed here overrides the same setting in CloudAEye's console settings.
On a pull request, CloudAEye reads it from the target branch, so a pull request cannot
change its own settings. -->
## Ultrareview
### Checks
<!-- A check set to false is not run. With Bugs, Security, AI slop score or Risk score false,
nothing is approved automatically. -->
<!-- - PR checklist: true --> <!-- true | false. Pull requests only -->
<!-- - Bugs: true --> <!-- true | false -->
<!-- - Security: true --> <!-- true | false. Includes leaked secrets -->
<!-- - AI slop score: true --> <!-- true | false -->
<!-- - Risk score: true --> <!-- true | false -->
<!-- - Architecture: true --> <!-- true | false -->
<!-- - Control flow: true --> <!-- true | false -->
<!-- - Task check: true --> <!-- true | false. Runs when a task is given -->
### Limits
<!-- Hard limits: a change above any of these is never approved automatically. Left out,
CloudAEye's own check applies. -->
<!-- - Risk score: 40/100 --> <!-- 0-100 -->
<!-- - AI slop score: 50/100 --> <!-- 0-100 -->
<!-- - Review severity: medium --> <!-- medium | low. The worst finding a change may have -->
### Human review policy
<!-- Pull requests only.
Auto-assign human reviewer: when CloudAEye does not approve a change automatically, it
names human reviewers for it on the pull request. With false it names nobody, and a human
must still look.
Max human reviewers to assign: the most people named, one by default. One is named unless
the instructions ask for more, and never more than this.
Instructions: plain words, as long as you like, carried on indented lines under the label.
They can ask for more review, never less. -->
<!-- - Auto-assign human reviewer: true --> <!-- true | false. Default true -->
<!-- - Max human reviewers to assign: 1 --> <!-- 1 | 2 | 3. Default 1 -->
<!-- - Instructions: Changes under `services/payments/` always need two humans. Pull requests
from the Platform team need one reviewer from outside the team. -->
## Review
<!-- /cloudaeye:inspect, /cloudaeye:security, /cloudaeye:review -->
### Severity floor
<!-- Report only findings at or above this. Ultrareview ignores it. -->
<!-- - Severity floor: all --> <!-- all | critical | high | medium | low. Default all -->
### LLM
<!-- Which models review the code, for the review commands and ultrareview's review; the other
commands use the models set in the console settings. Read from the repository's top-level
file only. Left out, each setting follows the console settings. A --model, --model-provider
or --invert-model option on a command wins for that run.
API key: with your own LLM and Provider openai, anthropic or deepseek. Write the name of an
environment variable that holds the key, like $OPENAI_API_KEY, so the key stays out of the
repository; a key written here can be read by anyone who can read the repository. Left out,
the key saved in the console settings is used (Settings > LLM > Bring your own LLM). -->
<!-- - LLM: CloudAEye --> <!-- CloudAEye | your own -->
<!-- - Provider: openai --> <!-- your own only: openai | anthropic | azure | aws_bedrock | gcp_vertex | groq | deepseek -->
<!-- - Model: gpt-6.1-terra --> <!-- CloudAEye: a model the console offers. Your own: the provider's exact model name -->
<!-- - Model inversion: true --> <!-- true | false. When AI authorship is detected, a different model family reviews the code. A Model or Provider set here wins over it -->
<!-- - API key: $OPENAI_API_KEY --> <!-- your own only: an environment variable that holds the key, or the key -->
### Paths never reviewed
<!-- Before a commit only. One path or pattern per line, relative to this file's directory. -->
<!-- - Skip: `**/generated/**` -->
## Control flow
<!-- /cloudaeye:control-flow. Ultrareview uses these too. -->
<!-- - Effort: medium --> <!-- low | medium | high. Default medium. How far the map follows calls -->
<!-- - Across repositories: true --> <!-- true | false. Default true -->
## Triage PRs
<!-- /cloudaeye:triage-prs. Read from the repository's top-level file only. -->
<!-- - OKRs: `docs/okrs-q4.md` --> <!-- your team's key results in plain words, or a file that holds them -->
# Review rules
<!-- Rules CloudAEye's review follows, in plain words: a heading, then the rule.
A rule covers this file's directory and everything below it. "Applies to" narrows it to
paths, relative to this directory.
A heading that is an id (r12) is one of your organisation's rules, synced into the
top-level file by /cloudaeye:config; change those in the console. Your own rules have no
id, and syncing never touches them. -->
<!--
## No request bodies in logs
Never log a request or response body; log its size and the route instead.
- Applies to: `src/api/`
-->
In a directory's .cloudaeye.config, leave out the ### LLM group and the ## Triage PRs
section: they are read from the top-level file only. The Settings Reference
explains every setting, and the examples show common setups with values filled in.
Format¶
The file is markdown, so it reads well on GitHub and in any editor:
##headings are sections (## Ultrareview,## Review) and###headings group settings inside them (### Checks,### Limits).- Each setting is a list item:
- Label: value. - The comment after a setting lists its options. Options are not case-sensitive.
- A setting inside comment marks (
<!-- … -->) is not read. - Yes-or-no settings take
trueorfalse. - Instructions are one paragraph, carried on indented lines under the label.
- Paths never reviewed take one path or pattern per line.
With a few settings given values:
## Ultrareview
### Checks
- Architecture: false <!-- true | false -->
### Limits
- Risk score: 40/100 <!-- 0-100 -->
### Human review policy
- Max human reviewers to assign: 2 <!-- 1 | 2 | 3. Default 1 -->
- Instructions: Changes under `services/payments/` always need two humans. Pull requests
from the Platform team need one reviewer from outside the team.
## Review
### Paths never reviewed
- Skip: `**/generated/**`
- Skip: `vendor/`
Where to Put the Files¶
Most repositories need one .cloudaeye.config at the root. A file can also sit in any
directory, and it covers that directory and everything below it, never a sibling directory.
For each changed file, CloudAEye reads every .cloudaeye.config from the root down to that
file's directory:
- The nearest file wins, setting by setting. A file in
services/payments/that sets only the risk limit takes that one setting from itself and everything else from the root. - Lists add up from the root down: instructions, paths never reviewed and review rules. A deeper file's paths are relative to its own directory.
- Some settings are read from the top-level file only: the LLM settings, since a review runs on one model, and Triage PRs. Set in a directory's file, they are left out and the command says so.
A Change Across Directories¶
When one change touches files under different settings, it gets whichever setting asks for more review:
- the lowest hard limits and the strictest review severity;
- the lowest severity floor, so more findings are reported;
- the most human reviewers;
- a check stays on unless every file's settings turn it off.
Which Version Is Read¶
- Before a commit, the commands read the files in your working tree, so a change to them takes effect on your next command.
- On a pull request, they read the files as they are on the branch the pull request merges into. A pull request cannot change its own settings: one that edits them says so, and the new settings apply once it is merged.
Working With Coding Agents¶
Coding agents with the CloudAEye plugin have a command that sets the files up for you:
/cloudaeye:config. It shows each setting with its value and options, one section at a time, and
you answer in your own words: risk 40, slop 50, turn off architecture, next, done.
/cloudaeye:config choose where the settings apply, then go section by section
/cloudaeye:config services/payments settings for that directory and below
/cloudaeye:config rules sync the rules and add one of your own
- A new file starts from the console settings. When the repository has no
.cloudaeye.config, the command offers to start one from your console settings: this repository's, or your account's. Only what differs from CloudAEye's defaults is written, so the new file says no more than the console settings do. - Every run syncs your organization's review rules from the console into the top-level
.cloudaeye.rules. Rules you wrote yourself are never touched. - It places only
.cloudaeye.configand.cloudaeye.rules, in your working tree.
Going Back to the Defaults¶
Delete a file to go back. Its directory then follows the .cloudaeye.config above it, or the
console settings when there is none. To put back a single setting, comment its line out again, or ask
/cloudaeye:config to set it back to its default.
Mistakes in the File¶
You can edit the files by hand. Nothing in them can stop a command from running:
- A value that is not one of the options is left out, its default applies, and the command names the line.
- A setting written twice in one file is named, and the later line is used. Paths never
reviewed are the exception: each
Skipline adds a path. - A top-level-only setting in a directory's file is left out and named.
- An API key that is not a key, or an environment variable that is not set, is named without showing the key, and the key saved in the console settings is used.