The /mo signup flow always starts with Slack so Mo can read where your team records decisions. After that, you connect GitLab inside the Mo portal, choose which projects to watch, then open merge requests as usual—Mo checks each MR’s diff against approved decisions before merge.
Slack
→
GitLab
·
MR checks
On the live app, /mo shows the Start using Mo card. The primary action is Start with Slack: the app creates your check session, then sends you through Slack’s install screen so Mo can join your workspace.
Until Slack is authorized, you won’t have the Mo portal project where GitLab is connected. If you haven’t done this yet, follow the full walkthrough on Installing Mo from Slack, then come back here for GitLab.
After Slack install completes, the app keeps you in check mode and lands you in the Mo portal (/mo-portal in the product). The Overview page lists the setup steps; when it’s time to wire up code, use the Connect GitLab control (the same action appears in the Integrations flow).
Clicking it starts GitLab’s OAuth (or personal access token) sign-in with Motionode. Approve the permissions GitLab shows so Mo can read project metadata, merge requests, and diffs for the projects you select—nothing in this step replaces your normal code review; it lets Mo compare the MR to what Slack says was approved.
After GitLab is linked, pick the projects / repositories Mo should monitor. Until at least one project is selected, Mo won’t attach checks to real merge requests.
If your GitLab token expires later, return to the same Integrations / Overview area, reconnect GitLab, and confirm project selection. You don’t add config files inside the repo for this flow.
Work like you already do: push a branch and open a merge request on GitLab—from the link Git prints after git push, or from your project under Merge requests → New merge request.
For every new MR on a watched project, Mo reads the diff and checks it against approved decisions captured from Slack (for example when someone uses @mo to record approval). When something conflicts, Mo surfaces that on the merge request (for example as a comment) so you can fix it before merge.