Developer Quickstart

This quickstart helps a developer user move from access readiness to running and understanding the first review.

Supported public path: GitLab artifact-first

Start with the artifact flow first, then add optional merge request feedback later if your team needs it.

This guide covers the supported public SaaS path. Deeper operator, self-hosted, and private-rollout variants are outside this guide.

Outcomes

• Confirm whether access is ready for the supported public path.
• Run the first review flow and locate the generated artifacts.
• Understand the high-level result and continue into shared output and feedback guidance.

1. Confirm access is ready

Before you run the review flow, make sure the admin has already connected the GitLab project, configured the review job, and shared the expected merge request path with you.

Success check

• You can access the GitLab project and merge request pipeline for this workflow.
• You know where the PatchPatrol job will appear when the review runs.

2. Ask your admin to confirm

If anything is still unclear, ask your admin to confirm:

• You were added to the correct GitLab project or group.
• The PatchPatrol job is configured on merge request pipelines.
• The first run is still using artifact-only feedback mode.
• The provider endpoint, model, and readiness checks are already in place.

For the canonical handoff and access details, use Access and roles.

3. Run the review flow

Open or update the merge request that should be reviewed, then wait for the PatchPatrol job to complete on the supported GitLab pipeline path.

• Use the normal merge request workflow for your team.
• Watch the review job instead of looking for inline merge request comments first.
• Treat the artifact output as the baseline source of truth for the first successful run.

Success check

• The PatchPatrol review job finishes on the merge request pipeline.
• You can open the job page and inspect its artifacts.

4. Find the review artifacts

Go to the completed review job and open the generated artifacts:

• ai-review.md for the human-readable review summary
• ai-review.json for the machine-readable review data

Start with ai-review.md when you want the fastest high-level read, then use ai-review.json when you need the structured details behind the same run.

Example: locating the artifact set in GitLab

The expected artifact path is .ai-review/ai-review.md and .ai-review/ai-review.json.

What to notice: open .ai-review/ai-review.md first for the quickest read. Open .ai-review/ai-review.json when you need reason codes, meta.* fields, or data for automation.

Success check

• You can locate both ai-review.md and ai-review.json.
• You know which artifact to open first for a quick review of the run.

5. Interpret the result

Use the first run to answer three questions:

• Did the review complete on the supported path?
• What findings or risk signals appear in ai-review.md?
• Do you need the structured detail in ai-review.json to triage or automate follow-up?

This guide keeps interpretation at the high-level result layer. The shared follow-on pages cover deeper output reading and optional delivery modes next.

Success check

• You can explain the outcome of the run at a high level.
• You know when to stay in the markdown summary and when to open the JSON artifact.

6. Continue with outputs and feedback

Next step: Understand the first review output

Also continue with:

• Access and roles
• Feedback modes
• Troubleshooting