---
sidebar_position: 4
title: Bug-autofix agent
---

# `bug-autofix` — ticket → fix PR → tracker writeback

The flagship orchestrator agent. It polls a tracker for new bugs, classifies each one, opens a fix PR for the autofixable ones, and writes the result back to the tracker — chaining three reusable building-block agents via **sub-graph dispatch**.

```
poll (this graph)
  ↓ found a ticket?
triage     → sub-graph: ticket-triage      → { severity, shouldAutofix, summary }
  ↓ severity ≥ AUTOFIX_MIN_SEVERITY AND shouldAutofix AND repo configured?
  ├─ yes → code_fix → sub-graph: code-fix  → { pr_url, branch }
  │            ↓
  └─ no ───────────────────────────────────────────┐
                                                     ↓
writeback  → sub-graph: tracker-writeback   (runs on BOTH branches)
  ↓
 END
```

High-severity, concrete, autofixable bugs get a fix PR opened and the Jira ticket moved to *In Review*. Everything else (noise, vague, too-big, below threshold, or no repo configured) is triaged and a human is notified — no PR.

## The three building-block agents

`bug-autofix` is an orchestrator: each step is a separate, independently deployable agent it dispatches as a sub-graph. Deploy all four in the same project.

| Step | Building block | Input | Output |
|---|---|---|---|
| `triage` | `ticket-triage` | `{ ticket }` | severity (`CRITICAL…NOISE`), `shouldAutofix`, summary |
| `code_fix` | `code-fix` | `{ ticket, repo }` | `{ pr_url, branch }` — clones, fixes with an inline test-gate, opens a PR |
| `writeback` | `tracker-writeback` | `{ ticket, pr_url?, branch?, result }` | transitions the issue, comments the PR link, posts to Slack/Lark |

Each block is usable on its own — `ticket-triage` is a fine standalone classifier; `code-fix` is a standalone clone→fix→PR agent.

## Sub-graph dispatch

A child step is declared with `{ workflow }` on the node:

```js
graph.addNode('triage', {
  workflow: 'ticket-triage',                  // child deploy slug
  input:  (state) => ({ ticket: state.poll.ticket }),
  output: 'classify',                         // dot-path on the child's final state
});
```

The engine spawns the child as a **separate execution** (its own run row + Fargate task, or in-process when runtime tags match), links it to the parent for the Activity-tab tree and cancellation cascade, polls until terminal, and extracts `output` back into the parent state under the node name.

## Trigger

Cron poll (default) or per-ticket webhook. Each run processes ONE ticket; the next tick/webhook handles the next.

```json
{ "jql": "issuetype = Bug AND statusCategory != Done ORDER BY updated DESC" }   // cron
{ "ticketKey": "PROJ-123" }                                                      // webhook
```

## Config (ENV tab)

| Var | Meaning |
|---|---|
| `REPO_URL` | Repo the fix targets. Unset → no autofix, notify-only. |
| `REPO_NAME` | Short repo name (default: derived from `REPO_URL`). |
| `REPO_BRANCH` | Base branch (default `main`). |
| `AUTOFIX_MIN_SEVERITY` | Routing floor for code-fix (default `MEDIUM`). |

Plus the children's own config: Jira connected (triage/poll/writeback), GitHub connected (code-fix), and `SLACK_CHANNEL` / `LARK_RECEIVE_ID` (writeback).

## Scope (v1)

- **In:** poll → triage → (autofix?) → code-fix → writeback, end-to-end to "PR opened + Jira written back".
- **Out:** deploy / verify / rollback; an auto re-dispatch loop; in-engine approval. The open PR is the human gate.
- **Tracker seam:** Jira is implemented; GitHub / Linear are extension points in the child templates.

## Deploy

```bash
zibby agent templates                         # browse the marketplace
zibby agent new bug-autofix -t bug-autofix    # scaffold the orchestrator
# ...also scaffold + deploy ticket-triage, code-fix, tracker-writeback in the same project
zibby agent deploy bug-autofix
```
