Resolve & Fix Workflow

This is oversight's differentiator. Resolve doesn't just review code — it reads all review feedback, implements every fix, runs a full self-review CR loop until clean, reorganizes commits by area of concern, and pushes. End-to-end, from findings to fixed code.

Overview

The resolve workflow picks up a pull request and drives it to completion. It reads the PR description, diff, and all review comments, then systematically addresses every actionable finding — Critical, Important, and Suggestions alike. The goal is to finish the original author's work, not rewrite it.

After implementing fixes, resolve runs a full code review on its own changes using the same multi-agent review engine. If that review surfaces new findings, it fixes those too and reviews again. This loop continues until a complete round returns zero actionable findings. Only then does it push.

The Full Pipeline

Step 1: Build Context

Resolve starts by gathering everything it needs to understand the PR:

• PR description and full diff via gh pr view and gh pr diff
• All review threads and comments from the GitHub API
• The PR's branch name and fork status (is it a fork? can the maintainer push?)
• The most recent oversight review, if one exists (either from an explicit link or the latest completed review task for this PR)

Step 2: Fix Merge Conflicts

Before addressing review findings, resolve checks the PR's merge status. If the branch has conflicts with the target, it runs a conflict resolution pass first using the merge-fix prompt. This ensures the codebase is in a clean state before any review fixes are applied.

Step 3: Implement Fixes

Resolve addresses every actionable finding from reviews and comments:

• Bug fixes for Critical and Important findings
• Code improvements for Suggestions
• Test additions or updates for every fix that changes observable behavior
• Items that require architectural changes beyond scope are documented with clear code comments

Resolve stays within the scope of what the PR is trying to accomplish. It does not refactor unrelated code or add unrelated features.

Step 4: Self-Review CR Loop

After implementing all fixes, resolve runs a full code review on its own changes. This is the same multi-agent review engine used for standalone reviews, including strategy selection:

• Standard 6-Agent CR for diffs under 2,000 lines
• MSAL for larger diffs with independent modules
• Focused rounds for large diffs without clear module boundaries

If the self-review finds issues, resolve fixes them and runs the review again. The loop exits only when a complete round of all agents returns zero actionable findings.

Step 5: Reorganize Commits

After the CR loop exits clean, resolve reorganizes all its fix commits by area of concern and purpose. The original PR author's commits are left intact. Iterative fix-up commits like "fix lint" or "address review round 2" are eliminated — each final commit describes what was done and why.

Step 6: Quality Checks

Before pushing, resolve runs a full quality check sequence:

1. Commitlint — if the repo uses conventional commits, all messages must comply
2. Tests — the full test suite must pass
3. Formatters — Prettier or equivalent must report clean
4. Linters — ESLint or equivalent must pass
5. Build — a full build must succeed (not just tsc --noEmit)

Step 7: Push and Verify

Resolve pushes to the PR branch and checks CI status. After pushing, it automatically approves any pending GitHub Actions workflow runs triggered by the new commits.

Fork PR Handling

When a PR comes from a fork where maintainerCanModify is false, resolve cannot push to the fork's branch. Instead, it creates a superseding PR:

1. Pushes commits to a branch on the upstream repo (same branch name)
2. Opens a new PR targeting the same base branch, with credit to the original author
3. Comments on the original PR explaining the situation and linking the new PR
4. Offers the original author the option to cherry-pick the fix commits instead

The resolution report notes the new PR number and links to it.

Triggering Resolve

POST /api/tasks
Content-Type: application/json

{
  "repoId": 1,
  "itemNumber": 42,
  "taskType": "resolve",
  "params": {
    "reviewTaskId": "abc123-..."
  }
}

The optional reviewTaskId parameter links the resolve to a specific review. If omitted, resolve looks up the latest completed review for the PR. If no review exists, resolve still works — it reads PR comments and review threads directly from GitHub.

Configuration

Monitoring Progress

Resolve tasks report progress in real time via Supabase Realtime. The progress object includes:

• step — current phase: preparing, checking, fixing-conflicts, running, approving-workflows, complete
• message — human-readable status, including the last meaningful line of output
• percent — estimated completion percentage (0-100)
• output — rolling window of the last 50 lines of CLI output

The web UI renders this as a live progress view with streaming output.

Resolution Report

When resolve completes, it produces a structured report separated by a ---RESOLUTION-REPORT--- marker. Everything after the marker is stored as the task result and shown in the UI. The report includes:

• What was fixed and how
• What was skipped and why (with code comments in the source)
• Commits made, grouped by area of concern
• Final CI status
• New PR link (for fork PR scenarios)

If the original review had a Notion page, the resolution report is also synced to Notion as a follow-up.

Retry and Error Handling

Resolve includes built-in retry logic for transient failures (API rate limits, network timeouts). If the Claude CLI encounters a retryable error, it backs off exponentially (30s, 60s, 90s) and retries up to 3 times.

Non-retryable failures (missing GitHub token, deleted PR branch, permission errors) fail immediately with a descriptive error message stored in the task record.

How It Differs from Review