Skip to main content
Every application carries an Ankra AI panel that decides which AI lanes run on that application’s repository. Open the application, then ⋯ → Settings → Ankra AI. Each lane follows your organisation’s source-control defaults until this application overrides it. The panel is a view onto the same per-repository settings the review lanes read when an event arrives, so what you set here and what your organisation’s source-control connection sets can never disagree.
The panel needs an application linked to a GitHub repository with the Ankra GitHub App installed on that repository’s owner. Without one it renders the reason instead of the lanes: the application has no repository yet, the App is not installed for the owner (install it under AI → Settings → Connections), or the application is on a provider the lanes cannot mint a repository token for - AI lanes are available for GitHub App repositories today.

​
The lanes

Every lane is off for a repository nobody has configured. A fresh source-control connection must never start reviewing, replying, or deploying on its own, so each lane is switched on deliberately - here, or for the whole connection under AI code review.
Code review and Actions review are labelled Not available yet and their switches are disabled. Their cards describe what the lanes will do; nothing runs. On Pull request review, the When it finds something choice is stored but not acted on yet - that lane comments today whichever option you pick, and the card says so.

​
Inherit or override

Every card is labelled either Inherited - it follows your organisation’s default for this connection - or Overridden, meaning this repository pins its own value. Edits stage locally until you press Save AI settings, and only the lanes you touched are sent. A lane you never touch keeps inheriting, which is what lets an organisation admin go on steering every application that has not opted out. Overriding a lane pins the whole lane: the values on the card when you save become this repository’s settings for it, and later changes to the organisation default stop reaching that lane. Two controls undo it:
  • Reset to organisation default on a card returns that one lane to the organisation, and says which way the organisation has it (on or off).
  • Follow organisation for everything, at the top of the panel, drops this repository’s override entirely so every lane inherits again.

​
What you can set per lane

Demo URL has no settings of its own here - it is on or off. What a preview deploys comes from the application’s demo defaults; see environment variables and a throwaway database. Turning the lane off stops the automatic pull-request previews for this repository without touching manually launched preview demos.
Mentioning Ankra in a pull request comment always gets an answer: a mention reply is a direct request from a human, so it is never filtered by branch scope, draft state, or either review budget. The run still counts toward the budgets.

​
Which skills the Org skills review uses

The Org skills review is a second pass that rides on the pull request review and appends an Organisation skills section to the same comment, so it runs only when Pull request review runs too. It judges the change against:
  • every skill marked Always active, and
  • the skills pinned in this lane’s skill_ids.
Skills of every kind count: core, CI/CD and add-on alike. One review uses at most 12 skills, always-active ones first, with at most 24,000 characters of skill text. With no always-active or pinned skill, the lane posts nothing. Only the Org skills review reads skill_ids (the skills lane in ankra application ai-config). The field also appears on the other lanes in the CLI and API output, but no review reads it there. The panel has no skill picker yet, so marking a skill Always active is how to put it in front of the review today. That also adds it to every AI conversation; see AI Skills. To steer the pull request review itself, use its review instructions: per connection under AI code review, or per repository as the pull request lane’s custom_instructions (at most 4,000 characters). A repository override pins the whole lane, as described under Inherit or override.

​
Settings are per repository, not per application

These settings are keyed by the repository, not by the application. Two applications connected to the same repository share one set of lane settings - turning a lane off on one turns it off for the other, and each application’s panel renders the other’s edits as its own. The preview lane also fires once per matching application, so such a repository collects one preview comment per application on every pull request. Keep one application per repository until per-application keying ships.