.vemlor.json

Declarative per-repo guidance. vemlor reads it as project context; it never executes anything.

Drop a .vemlor.json file at your repository root to give vemlor project-specific guidance: the commands it should know about and any house rules for that repo. Every task in that repo picks them up automatically.

{
  "$schema": "https://app.vemlor.com/schemas/vemlor.v1.json",
  "version": 1,
  "verify": {
    "test": "go test ./...",
    "lint": "golangci-lint run ./...",
    "typecheck": "go build ./..."
  },
  "agent": {
    "instructions": [
      "Run gofmt on changed Go files.",
      "Do not edit generated files manually."
    ]
  }
}

Add the $schema line and your editor autocompletes and validates the file as you type.

Fields

Field	Type	Description
`$schema`	string	Editor schema URL.
`version`	integer	Schema version; omitted defaults to `1`.
`verify.test`	string	Advisory test command.
`verify.lint`	string	Advisory lint command.
`verify.typecheck`	string	Advisory type-check command.
`agent.instructions`	string array	Additional repository guidance.
`review`	object	Code reviewer for this repo's PRs. See Code review.
`ci`	object	CI auto-fix policy for this repo. See CI auto-fix.

Limits: 64 KiB per file, 1,000 bytes per verification command, 20 instructions, and 2,000 bytes per instruction. Unknown fields and control characters are rejected.

Code review

vemlor can review new pull and merge requests and leave inline comments. Reviewing stays off until you name a reviewer — watching a repo never turns it on by itself.

{
  "review": {
    "reviewer": "alibaba-opencodereview",
    "mode": "on-open",
    "ignore": ["vendor/**", "**/*.snap"]
  }
}

Field	Type	Default	Description
`review.reviewer`	string	none	Which reviewer to use. Empty or omitted means no review.
`review.mode`	string	`on-open`	`on-open` reviews when the request opens or updates; `manual` reviews only when you ask from the UI or a comment.
`review.ignore`	string array	none	Path globs the reviewer never comments on.

Reviewers you can name:

`reviewer`	What it is
`alibaba-opencodereview`	Alibaba's open code reviewer.

Setting the id is all it takes — a reviewer needs no extra connection. More reviewers are on the way.

CI auto-fix

When a pull request's CI goes red, vemlor can open the fix. The ci block controls how it behaves on your PRs. (A PR that vemlor opened itself is always fixed immediately — that's not configurable.)

{
  "ci": {
    "autofix": "manual",
    "delay": "30m",
    "maxAttempts": 3,
    "branches": ["main"],
    "ignoreChecks": ["codecov/*"],
    "schedule": ["after 08:00 and before 18:00 every weekday"],
    "timezone": "Europe/Vienna"
  }
}

Field	Type	Default	Description
`ci.autofix`	string	`manual`	`manual` comments and waits for your 👍; `auto` fixes on its own; `off` does nothing.
`ci.delay`	duration	`30m`	With `auto`, how long to wait after a failure before fixing — lets flaky runs and quick manual fixes settle.
`ci.maxAttempts`	integer	inherits account default	How many fix attempts before giving up.
`ci.branches`	string array	all	Only watch PRs targeting these branches.
`ci.ignoreChecks`	string array	none	Check-name globs that never trigger a fix.
`ci.schedule`	string array	24/7	Only act inside these time windows (see below).
`ci.timezone`	string	account tz	IANA timezone the schedule is evaluated in.

Modes

manual (default) — vemlor leaves one comment on the PR: "CI is failing — want me to fix it?" Reply 👍 or @vemlor fix and it goes. No surprise commits; nothing happens until you ask.
auto — vemlor waits out delay (and any schedule window), then pushes the fix on its own.
off — vemlor never touches your PRs' CI.

Schedule

Windows use a small subset of the familiar cron-in-English syntax:

"schedule": ["after 08:00 and before 18:00 every weekday"]

Supported: after HH:MM, before HH:MM, every weekday, every weekend, and day lists like on monday, wednesday. Times are 24-hour and evaluated in ci.timezone. Outside a window vemlor holds the fix until the window opens — it never drops it. A schedule string it can't parse is reported and ignored (it will not silently fire at the wrong time).

Guidance, not automation

The file is guidance only. vemlor hands its contents to the agent as clearly-labelled project context on every run in that repo. It never runs anything on its own from it. Executable fields such as setup and hooks are rejected.

Repository contents may be modified by an untrusted contributor, so vemlor treats the file as untrusted input: it strictly parses and bounds every field and labels the resulting prompt content as untrusted. Repository guidance cannot override system policy, user intent, credential rules, sandbox restrictions, or tool permissions.

Feedback in the thread

Missing file: silent no-op, nothing changes.
Invalid file: skipped, never fails your task, with a Ignored .vemlor.json (invalid): … note in the thread so you can fix it.
Valid file: applied, and the thread shows exactly what landed, e.g. Applied repository guidance from .vemlor.json: 1 verify hint, 2 instructions.