# How EkLine opens pull requests

EkLine opens pull requests (merge requests on GitLab) only in the repositories you select for documentation. Your team reviews and merges them.

## Where EkLine writes and where it only reads

You select repositories in **Settings** > **Integrations** > **GitHub Integration** (or **GitLab Integration**), in two lists:

| List | Shown as | What EkLine does there |
| --- | --- | --- |
| **Where EkLine writes** | **Write access** | Opens pull requests with documentation changes. Select the repositories that hold your docs. |
| **What else EkLine can read** | **Read-only** | Reads code and pull requests to work out what changed and why. Never writes. |

In every agent session, EkLine blocks:

- edits to files outside the **Where EkLine writes** repositories
- `git push` to any other repository
- GitHub and GitLab command-line writes, such as creating a pull request, aimed at any other repository

EkLine can still comment on pull requests in your read-only repositories. That is how [automatic PR review](/agent/automatic-pr-review/) and replies to `@ekline-ai` work.

The Marketing Agent works under the same list. Its drafts stay in the editor until you ask it to publish one to a documentation repository.

For EkLine's security compliance and subprocessors, see the [trust center](https://ekline.io/trust-center).

## When EkLine opens a pull request

The agent opens a pull request as a step in a session. It opens one in these cases:

| Where the work started | When the agent opens a pull request |
| --- | --- |
| [The editor](/agent/editor/) | You click **Raise PR**, which puts "Open a pull request" in the message box, and send it. |
| A comment that mentions `@ekline-ai` on a pull request or merge request | When the comment asks for a documentation change. A question gets an answer and no pull request. |
| [Slack](/agent/slack-bot/) | When the request changes docs files and **Automatically raise PRs from Slack requests** is on (the default) in **Settings** > **Docs Agent** > **Slack triggers**. |
| An [automation](/agent/scheduled-agents/) | When **Raise a pull request** is checked under **Notifications**. |
| A [Jira trigger](/agent/jira-triggers/) | Once for each ticket the trigger picks up. |
| [Automatic PR review](/agent/automatic-pr-review/) | When it rates a code pull request High, it starts the Docs Agent on the update. |
| The Marketing Agent | Only when you ask it to publish a draft to a documentation repository and say where. |

When **Auto-create documentation PRs** is off in a repository's [review rules](/agent/review-rules/), comments on that repository's pull requests leave drafts in the editor. You raise the pull request yourself. If you don't see that setting, EkLine always opens the pull request. To get the setting, contact support@ekline.io.

If no pull request appears when you expect one, open the session and ask the agent to open one.

## What a docs pull request contains

On GitHub, EkLine opens the pull request as the EkLine GitHub App. On GitLab, it opens the merge request as the user who owns the access token you connected.

A docs pull request from EkLine has:

- A branch with a `docs/` prefix, based on the repository's default branch.
- A title and commit messages that start with `docs:`, followed by what was documented.
- A body that says what was documented, why, and how a reviewer can check it. It also lists any of your Review rules the change could not meet.
- A body that ends with "📝 Created with EkLine · View session", where **View session** links to the session in EkLine.
- No labels. It opens ready for review.
- Reviewers from **Settings** > **Docs Agent** > **Reviewers**: everyone under **Default reviewers**. When **Auto-assign reviewer** is on, it also adds the person who started the request: the Slack user who mentioned EkLine, or the author of the source pull request. If EkLine finds no reviewer, it opens the pull request anyway.

Before it commits, the Docs Agent checks its changes against your rules of type **Review** (**Settings** > **Docs Agent** > **Rules**). It also runs a style review. A failed style review never stops the pull request. A pull request from the Marketing Agent has no style review.

## Confidence ratings belong to code pull requests

Low, Medium and High are the ratings [automatic PR review](/agent/automatic-pr-review/) gives a code pull request. They say how likely the change is to need a docs update. You see them in the session, as "Documentation impact confidence", and as a dot in the sessions list. They never appear in a docs pull request. By default the agent posts nothing for Low, a short comment for Medium, and a comment that starts the Docs Agent for High.

## GitLab differences

- EkLine opens merge requests on gitlab.com projects.
- Merge requests and replies are posted as the user who owns your organization's GitLab access token, not as a bot.
- If the access token is missing, or GitLab rejects it, the agent stops before it changes anything. It asks you to reconnect GitLab in EkLine settings.
- The agent tries to add the same reviewers. A name that is not a GitLab user is left off, and the merge request opens anyway.
- A comment that mentions `@ekline-ai` on EkLine's own merge request starts a new session. It does not continue the one that opened the merge request.

## Ask for changes

- **In the editor:** open the session from the pull request's **View session** link, ask for the change, and review it. Then click **Update PR**. It puts "Update pull request #N with my latest changes" in the message box. Send it.
- **On GitHub:** mention `@ekline-ai` in a comment on EkLine's pull request. EkLine reacts with 👀 and continues the session that opened the pull request, on the same branch.
- **On GitLab:** mention `@ekline-ai` in a comment on the merge request. This starts a new session.

In the editor and on GitHub, the agent pushes a new commit to the same pull request. It leaves the title, body and reviewers as they are.

## FAQ

### Will EkLine open pull requests on our code repositories?

No, unless you add a code repository to **Where EkLine writes**. Repositories under **What else EkLine can read** are read-only: EkLine blocks pushes and pull request commands aimed at them. It does comment on their pull requests, when automatic PR review covers the repository or when someone mentions `@ekline-ai`.

### Who can ask EkLine for changes in a comment?

On GitHub, someone with write or admin access to the repository, or a member of the GitHub organization. On GitLab, a project member with the Developer role or higher. Anyone else gets a reply saying EkLine responds only to members and collaborators.

### Why did EkLine not answer my second comment straight away?

A session works on one request at a time. On GitHub, a later comment waits for the current one to finish, for up to five minutes. If it is still waiting after that, EkLine replies "Sorry, I encountered an error while processing your request. Please try again later." Comment again when the first request is done.