How Dualzo turns GitHub issues into pull requests

1. Connect a repository in any language

Install the Dualzo GitHub App on the repositories you choose, then connect one. Dualzo indexes it: it detects the ecosystem and main language, parses the manifest, maps the folder structure and tests, and reads your CI configuration. Indexing only reads files — it never runs your code.

From your package scripts, Makefile targets, and CI steps, Dualzo proposes the commands that define "passing" for your repository: install, lint, typecheck, test, and build. An admin reviews and confirms them. Until then, no task can run on that repository.

2. Start a task from a GitHub issue or a prompt

Add the dualzo label to a GitHub issue, or write a prompt in the app. You can also schedule a task for a later date, start one from a TODO or FIXME that indexing found, or let Dualzo open a fix task when CI fails on your default branch (both opt-in per repository).

3. Dualzo writes a plan

Dualzo sends the issue and a budgeted slice of what it knows about your repository to the model you picked — Claude, Codex, or Gemini. The model returns an ordered plan: tasks with instructions and acceptance criteria, the files expected to change, the commands to run, a risk level, and rollback notes.

Each plan also gets a confidence score from 0 to 100. Dualzo calculates it itself, from how many files will change, whether those files have tests, whether a test command is confirmed, and your workspace's past pass rate. The model does not grade its own work.

4. A human approves it

Workspace admins get the plan by email, and in Slack, Microsoft Teams, or Google Chat if you connect them. The links are signed, single-use, and expire. Approve starts the work, Modify sends your instructions back into planning for a new plan, and Reject ends the task. No code is written before this step.

5. It runs the plan one task at a time

Dualzo creates a branch from your default branch and runs the tasks in order. Each task gets its instructions, the context it needs, and the output of earlier tasks, and each is committed separately. Only one task runs on a repository at a time.

6. Every task is validated in a sandbox

After each task, your confirmed commands run in order inside a throwaway container: no network except during install, read-only outside the working copy, strict CPU, memory, and time limits, and none of Dualzo's secrets. If a command fails, its output goes back to the model for up to two fix attempts.

7. A pull request is opened — only when everything passes

When every check is green, Dualzo pushes the branch and opens a pull request with a summary, what changed per task, a testing checklist, rollback instructions, which commands ran, and a link to the full audit trail. A pull request cannot be opened while validation is failing. Dualzo never merges — your team reviews and merges as usual.

When a task fails

If validation still fails after the fix attempts, the task stops for review. You see the plan, each task's status, the full diff, and the failing output, and you choose what happens next:

• Abandon — the branch is deleted and the task closes.
• Edit plan and re-run — your instructions go back into planning, and the new plan needs approval again.
• Take over — the branch is pushed as it is and opened as a draft pull request, clearly marked as not validated.

Everything is on the record

Every webhook, plan, approval, task, validation run, and pull request is written to an append-only audit log, with a timeline for each task. Read more about how Dualzo protects your code on the security page.