Commands in comments

You can ask CodeLotse to act on a pull request or an issue by mentioning it in a comment. There are no slash commands; every command starts with a mention of the bot.

The mention

The mention is the user name of the account CodeLotse posts with:

Code host	Mention
GitHub	The slug of the GitHub App, without [bot]. An app created from the manifest is usually @codelotse; use the name shown on the bot's comments if the app was renamed.
GitLab, Azure DevOps	The user name of the account the connection uses (see providers.md).

Pull request commands

Write the command on the first non-empty line of a new comment. Text on the following lines is allowed and ignored.

@codelotse explain

Command	Effect
explain	Explains the finding the comment replies to, using the finding and the surrounding code at the head of the pull request.
why	Explains why the finding matters.
fix	Replies with a proposed change. It is a suggestion block you can commit from the code host only under the same conditions as review suggestions (see Suggested changes), and only when the replaced lines are exactly the lines of the comment thread; otherwise the change is shown as a plain code block. No suggestion is offered for CI configuration or lock files.
ignore	Ignores the finding for this pull request. Later reviews of the pull request mark it as suppressed. Security findings of high or critical severity cannot be ignored.
re-review	Starts a new review of the current head commit, unless that commit was already reviewed.
learn <text>	Proposes <text> as a learning for the repository (see Learnings). Unlike the other commands it takes text.
describe	Writes the CodeLotse block of the pull request description again from the current diff (see Pull request description and title).
title	Suggests a pull request title, or sets it when the repository allows it.

The line must match exactly:

• the mention, one or more spaces, the command in lower case, nothing else;
• at most three leading spaces; quotes (>) and code blocks are not commands;
• re-review is written with a hyphen; fix this or @codelotse IGNORE are not commands. When free-form questions are allowed, they are answered as questions (see below).

Where commands work

• explain, why, fix and ignore work only as a reply in the review thread of a finding that CodeLotse posted.
• re-review, describe and title work in a finding thread and as a normal pull request comment.
• Edited comments and comments by bots are ignored.

Code host	Finding threads	re-review
GitHub	yes	yes
Azure DevOps	yes (threads on a file)	yes
GitLab	not reliably: replies are not linked to the finding thread	yes

Who can use them

• You need write or admin access to the repository. Commands from other users are refused and recorded in the audit log.
• An admin must turn on Commands in pull requests for the repository (chat mode). It is off by default. In shadow mode commands are recorded but not answered; in approval mode answers wait in the approvals inbox.
• An admin can limit which commands are allowed under Commands in pull requests › Allowed commands.
• Each pull request accepts 10 commands per hour and each user 20 per hour by default.

Refused, rate-limited or disabled commands get no reply.

Pull request description and title

describe and title are off by default. An admin turns on Pull request description for the repository (see configuration.md) and allows the commands under Commands in pull requests › Allowed commands.

• @codelotse describe writes the description block from the diff of the current head and the findings of the latest review. It also writes the block again after the author deleted it. It posts no comment; in approval mode the block waits in the approvals inbox.
• @codelotse title replies with "Suggested title: …" when Pull request title is set to suggest. When it is set to apply, CodeLotse sets the title, in the mode of the description. A review never changes the title.
• Both work on GitHub, GitLab, Gitea and Forgejo. On Azure DevOps and Bitbucket only the title suggestion works.

Issue command: fix

On an issue (not a pull request) a maintainer can ask CodeLotse to open a draft pull request that fixes it:

@codelotse fix

• The mention may include [bot] and is not case-sensitive here.
• The fix feature must be enabled for the repository and needs the fixer app (GitHub only). The command can be disabled separately; the trigger label (default quavon:fix) starts the same flow.
• You need write or admin access. The issue must be open and no fix may already be running. Limits apply per repository, per issue and per tenant.
• CodeLotse does not comment when an issue is not eligible; the reason is shown on the fix run in the web interface.

There is no pull request command for fixes. Fixes for the findings of a review are requested in the web interface (Apply fixes on a review run, or Fix on one finding); see configuration.md.

Free-form questions

When an admin allows Free-form questions, CodeLotse also answers other pull request comments that start with the mention:

@codelotse why does pay() charge euros here?

• The mention is the first thing on the first non-empty line (at most three leading spaces, not in a quote or code block) and is followed by a space or a line break. Everything after it, including the following lines, is the question, up to 2,000 characters. @codelotse, … and @codelotse-dev … are not questions; a mention alone is ignored.
• Exact commands keep their meaning: @codelotse explain runs the command. @codelotse IGNORE, @codelotse ignore this please and @codelotse fix this are questions.
• Free-form questions are off by default. Turn them on in the policy of the repository or in the organisation defaults: Commands in pull requests › Allowed commands › Free-form questions. While they are off, such comments are skipped without a reply and are not recorded.

Where the answer appears

• A question in the review thread of a CodeLotse finding is answered in that thread.
• A question anywhere else (the pull request conversation, the review thread of a person, a new comment on a line) is answered with a pull request comment. If the question was asked on a line, the answer starts with the file and line, for example src/pay.ts:12.
• On GitLab, replies are not reliably linked to finding threads, so answers usually appear as pull request comments.

What the answer is based on

• the question, the pull request title and description;
• the diff between base and head, up to 24,000 characters, starting with the file of the thread; files that do not fit are named;
• the finding of the thread, or 20 lines around the commented line of the file at the head;
• the titles and locations of the published findings of the latest review, up to 30.

Other comments and threads are never read. Every statement must cite lines of the changed files or of the commented file. CodeLotse checks each quote against those lines and lists the cited lines under the answer. Links, images, HTML and mentions are removed from answers.

If the model cannot answer, is unsure, cites lines that do not exist or cites nothing, CodeLotse posts this fixed text instead: "CodeLotse could not answer this from the pull request." Comments that are not questions, such as thanks, get the same text.

Modes and limits

• The same rules as for commands apply: write or admin access, refused questions recorded in the audit log, the rate limits per pull request and per user. Every question counts against the limits, also when CodeLotse cannot answer it.
• Shadow mode records the question but does not call the model. In approval mode answers wait in the approvals inbox. On public repositories automatic answers always wait for approval.
• The model cost is recorded under the chat feature.

Learnings

A learning tells later reviews about accepted team practice, for example why a pattern CodeLotse reports is fine in this repository. Learnings are proposals until a maintainer activates them on the Rules page (see configuration.md).

learn

@codelotse learn raw SQL is fine in migrations because they run once by hand

• The text follows learn on the same line (a colon after learn is allowed) and may continue on the following lines, up to 1,000 characters. Links, images, HTML and mentions are removed from it.
• learn works in a finding thread and as a normal pull request comment. An admin must allow it under Commands in pull requests › Allowed commands; it is not allowed by default. The same access rules and rate limits as for the other commands apply.
• CodeLotse stores a proposed learning for the repository and replies: "Proposed as a learning. A maintainer can activate it in CodeLotse." No model is called. In shadow mode nothing is stored.

Learning from replies

When learning is not off for the repository (Learning from feedback on the policy page), CodeLotse also reads replies in the review threads of its own findings:

• Only replies that do not start with the mention, written by an owner, member or collaborator of the repository, are read. Edited comments and comments by bots are ignored.
• A model decides whether the reply states a lasting practice with a reason. If it does, CodeLotse stores a proposed learning silently: there is no reply in the pull request. Thanks, promises to fix, questions, one-off exceptions and any request to ignore, skip or weaken security checks never become proposals.
• At most 20 proposals from replies are stored per repository and day. The model cost is recorded under the chat feature.

Fix in your coding agent

Every finding on the review page of the web interface has Fix in your agent, and the review page has Fix all in your agent for the open findings of the run (at most 20, most severe first). Both open a dialog with the prompt, Copy prompt and links that open the prompt in a coding agent on your computer:

Link	Opens
Open in Cursor	cursor://anysphere.cursor-deeplink/prompt?text=…
Open in Claude Code	claude-cli://open?q=…, on github.com with &repo=owner/name
Claude Code in VS Code	vscode://anthropic.claude-code/open?prompt=…
Open in Codex	codex://new?prompt=…

• Every agent only pre-fills the prompt. Nothing is sent until you confirm it, so read it first.
• A link is left out when the prompt is too long for it: Claude Code accepts at most 5,000 characters, the other links at most 10,000 characters after encoding.
• Claude Code finds the repository from repo only if you have run claude in a clone of it before. Otherwise it opens in the current directory.
• GitHub Copilot, Windsurf and other agents have no documented link for prompts: copy the prompt and paste it into their chat.
• Code hosts such as GitHub only allow http and https links in comments, so these links work only in the web interface. In pull request comments CodeLotse adds the prompt itself and, on public repositories, an https link to Cursor (see configuration.md).

Feedback without commands

CodeLotse also learns from how people react to its comments when learning is enabled: resolving a thread with or without a change, committing a suggestion, ignore commands, rejected approvals and, on private and internal repositories, thumbs-up and thumbs-down reactions on its comments. See analytics.md for the resulting numbers.