Analysis and PR automation
Configure analysis and review modes, follow asynchronous outcomes, and control automatic pull request publication.
Automate intake and PR creation separately
Prilog's production-to-PR workflow has separate controls for collecting signals, enabling analysis, and publishing generated changes. Choose them for the selected project before sending a continuous telemetry stream. Uploading a log file or importing an issue can trigger enabled automation and consume the project's allowance.
Understand the project's review mode
The fix workflow supports these action modes. The action-mode selector is not currently exposed in the public settings interface; contact support@prilog.ai to confirm or change the mode available for your project. Admins can pause or resume analysis in settings. For an explicit trial, use the CLI to review a diff and request PR creation.
| Mode | Behavior | Engineering control |
|---|---|---|
| Human review required | Generated changes wait for review before PR publication. | Inspect the analysis and diff, then request a PR. |
| Auto-create PR | Allows the workflow to create a PR for a generated fix. | Review changes and CI in the repository. |
| Auto-create PR + task | Allows the workflow to create a PR and route a follow-up task. | Review the PR and the configured task destination. |
Automatic PR publication requires the strict policy gate to return publish, an enabled workflow, a usable generated change, repository access, and the project's configuration. It does not grant an agent permission to merge or deploy.
Start with one connected service
- Connect its repository and branch.
- Bring evidence through an observability connection, monitoring SDK, or OTLP exporter.
- Confirm the project's analysis setting and review mode.
- Inspect the first investigations and PRs before increasing the workload.
- Check usage and set a monthly fix limit in billing settings when needed.
Use automatic bug fixing for an explicit CLI-driven trial. Keep credentials and personal information out of free-form log messages.
Understand completion states
An error can be pending, processing, completed, failed, or skipped. Completed analysis can still produce no code changes. An investigation may identify a configuration problem, lack enough evidence, or need additional engineering work.
Check prilog list, inspect the error in the dashboard, or use MCP get_error. Read the diff and the checks actually run. A queue response is not a completed fix, and a PR is not a merged resolution.
Avoid duplicate work in scripts
Use explicit project and error IDs. Hosted MCP writes require an idempotency key; reuse the same key and arguments for a retry of the same action. Check state after an interrupted request before creating another mutation. See MCP retry behavior and troubleshooting.
Evaluate the recurring workflow
Track accepted fixes, time spent reviewing, additional edits, recurrence after deployment, and cost per accepted fix. Compare against your previous process on representative incidents. The SWE-bench result measures benchmark issue resolution under its disclosed method, not ongoing production reliability.