MergeGuard

Your first week with MergeGuard

A practical day-by-day path: install on day 1, your first @mergeguards fix by day 3, and deep-scan by day 7.

You do not need to learn every command on day one. This guide walks through what most teams do in their first week—install, read a review, apply a fix, then run a deeper security pass when a PR deserves it.

Guest install is OK

On day 1 you can install the GitHub App and get reviews without a MergeGuard account. Link GitHub later from /github-app-setup or the homepage when you want the dashboard.

Day 1 — Install and your first review

Goal: MergeGuard comments on a real pull request or merge request within a few minutes.

  1. GitHub: From the homepage, click Install GitHub App (or use the direct install link). Select one repository to start—guest install works without sign-in.
  2. GitLab: Click Connect GitLab on the homepage, authorize OAuth, then connect a project from the dashboard. See GitLab quickstart.
  3. Open a pull request or merge request on a connected repo (even a small doc or dependency bump is fine).
  4. Read the summary on the Conversation / Overview tab—note the risk score and recommended fixes.
  5. Open Files changed and read inline comments on the lines you edited.

Done when: You see at least one inline finding or a clear “no issues” summary you trust.

GitHub quickstart → · How reviews work →

Day 3 — Your first @mergeguards fix

Goal: Let MergeGuard commit a patch from an inline review thread—not just suggest text.

  1. Pick an inline finding you agree with (style, bug, or small security nit—avoid huge refactors for your first fix).
  2. GitHub: Reply on that inline review comment thread with @mergeguards fix.
  3. GitLab: Reply on the Changes diff thread with @mergeguards fix.
  4. Wait for MergeGuard to push a commit to your branch. Refresh the PR/MR and confirm the diff matches the suggestion.
  5. If the fix is wrong, revert or push a follow-up commit—treat AI fixes like any other contributor patch.

Done when: A fix commit from MergeGuard is on your branch and CI (if any) is green.

Guest installs and the linked Free plan both allow @mergeguards fix within monthly review caps. See Plans & limits.

Command reference → · GitHub PR commands →

Day 7 — Deep-scan on a meaningful PR

Goal: Run a second, security-focused pass when a change touches auth, dependencies, infra, or a large diff.

  1. Open a PR/MR that is worth a deeper look (new API surface, dependency upgrade, Dockerfile change, etc.).
  2. After the automatic review lands, post @mergeguards deep-scan on the PR Conversation (GitHub) or MR Overview note (GitLab).
  3. Read the deep-scan summary—compare with the first-pass risk score and inline threads.
  4. For a lighter re-review without deep-scan, use @mergeguard-followup instead.
  5. Optional: on Pro+, Dockerfile changes can trigger an async container image CVE scan in a follow-up comment.

Done when: You have used deep-scan (or follow-up) deliberately—not on every tiny PR.

Plan note

@mergeguards deep-scan requires a linked workspace on Pro or higher. Free and guest tiers still get automatic reviews, OSV dependency signals, and @mergeguards fix. View pricing →

Command reference → · MergeGuard Intelligence →

After week one