> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodus.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Steer a Review (Focus)
> Direct Kody's attention to a specific area of a pull request with a one-off review directive, via PR comment or CLI
A **review directive** lets you tell Kody where to focus its deepest analysis for a single review. Instead of changing any configuration, you attach a short instruction when you trigger the review — for example, "focus on the auth and session logic" — and Kody spends its hardest analysis on the changed code that matches.
A directive is **ephemeral**: it applies to that one review run only. It is not saved to your settings and does not affect future reviews. To change Kody's behavior permanently, use [Custom Prompts](/en/how_to_use/code_review/configs/custom_prompts) or [Kody Rules](/en/how_to_use/code_review/configs/kody_rules) instead.
## When to Use It
* A PR touches many files but you care most about one risky area (auth, payments, a migration).
* You want Kody to trace the callers and callees of a specific change and challenge it harder.
* You're re-running a review and want to steer attention without editing any config.
## Priority, Not a Filter
This is the most important thing to understand:
A directive sets **priority, not a filter**. Kody prioritizes the focus area, but it still reports any concrete bug, security, or performance issue it notices **elsewhere** in the diff. It never suppresses findings outside the focus, and it never approves the rest of the PR unseen.
Use a directive to say *"look here hardest"* — not *"only look here."*
## How to Trigger It
Add your focus text right after the review command in a pull request comment:
```text theme={null}
@kody review focus on the auth and session logic
```
You can also use `start-review`, and combine it with `--force`:
```text theme={null}
@kody start-review focus on the new database migration
@kody review --force focus on error handling in the webhook parser
```
`--force` re-runs the review even when Kody would normally skip it ("no new commits since the last review"). Use it — with or without a focus directive — to get a fresh pass after fixing whatever made the previous run fail, or to apply updated settings to an already-reviewed PR.
Only the **first line** after the command is used as the directive. Everything on later lines is ignored, so keep your focus to a single line.
Works on GitHub, GitLab, Azure DevOps, Bitbucket, and Forgejo.
Pass the `--focus` flag when running a review:
```bash theme={null}
kodus review --focus "the auth and session logic"
```
See the [CLI commands reference](/en/how_to_use/cli/commands) for the full command surface.
## Heavy mode
**Alpha — access by request.** Heavy mode is not on by default for anyone. To try it, ask us
to enable it for your organization on [Discord](https://discord.gg/TFZBRk9fT6) or at
[support@kodus.io](mailto:support@kodus.io). Until then the flag is accepted but has no
effect — see [Availability](#availability) below.
A focus directive tells Kody *where* to look hardest. `--heavy` tells it to look *longer*: the
finder runs extra "what did you miss?" critic passes over the same diff, surfacing more real
issues at the cost of a slower review and more candidates to triage.
```text theme={null}
@kody review --heavy
@kody review --heavy focus on the payment reconciliation logic
kodus review --heavy
```
`--heavy` can sit anywhere on the command line — before or after your focus text — and it is
stripped from the directive either way, so `@kody review focus on the retry logic --heavy`
focuses on "the retry logic".
**To combine it with `--force`, put `--force` first.** `--force` is only recognized
immediately after the command word, so `@kody review --force --heavy` runs a forced heavy
review, while `@kody review --heavy --force` runs a heavy review that is **not** forced.
A dash is required: a bare `heavy` is read as directive text, so `@kody review heavy checkout
path` focuses on "heavy checkout path" rather than enabling the flag.
### Availability
Heavy mode is an **alpha** feature. It only runs for organizations we've explicitly opted in:
| | Status |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Cloud** | Available on request — we move your organization to the `alpha` release track. |
| **Self-hosted** | Not available yet. Alpha features stay off regardless of `BETA_FEATURES`; it ships to self-hosted once it's promoted to beta. |
**The flag fails open, not loud.** If your organization isn't opted in, `--heavy` is accepted
and the review **runs normally** — no error, no warning, no different result. If you asked for
access and can't tell whether it's active, ping us rather than assuming it ran.
To request access, message us on [Discord](https://discord.gg/TFZBRk9fT6) or email
[support@kodus.io](mailto:support@kodus.io) with your organization name.
Reach for it on the changes where missing something is expensive — a migration, an auth
change, a payment path — not as a default. On everyday PRs the extra candidates are usually
noise you have to filter.
## Writing a Good Directive
* **Be specific about the area, not the verdict.** "focus on concurrency in the queue consumer" works better than "find bugs".
* **Name the code, not the outcome.** Point at a module, flow, or concern ("the retry logic", "the SQL in the reports service").
* **Keep it short.** Directives are capped at **500 characters**; only the first line of a comment is read.
- `@kody review focus on the authentication and token-refresh flow`
- `@kody review focus on the new Stripe webhook handling`
- `kodus review --focus "race conditions in the background worker"`
* `@kody review please be thorough` — no area to prioritize.
* `@kody review only comment on file X` — a directive is not a filter; use [ignore paths](/en/how_to_use/code_review/configs/general) to scope files instead.
## Notes & Limits
* **Length:** directives are truncated at 500 characters.
* **First line only:** for PR comments, only the first line after the command becomes the directive.
* **Untrusted by design:** because anyone who can comment on the PR can supply a directive, the text is sanitized before use (control characters and angle brackets are stripped). This does not change your focus — it only prevents the text from tampering with Kody's internal prompt.
* **Not persisted:** nothing is written to your repository or organization settings.