# 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

1. Connect its repository and branch.
2. Bring evidence through an observability connection, [monitoring SDK](/docs/monitoring/), or [OTLP exporter](/docs/otlp/).
3. Confirm the project's analysis setting and review mode.
4. Inspect the first investigations and PRs before increasing the workload.
5. Check usage and set a monthly fix limit in billing settings when needed.

Use [automatic bug fixing](/docs/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](/docs/mcp/#asynchronous-workflow) and [troubleshooting](/docs/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](/docs/swe-bench-verified/) measures benchmark issue resolution under its disclosed method, not ongoing production reliability.