Close a bug straight from the ticket

When should you use the bug-from-ticket squad?

Use it for bugs that are already written up in a tracker and can be reproduced in code. The squad forces the discipline most quick fixes skip: prove the bug with a failing test, fix the cause, then have someone else read the fix.

• Good fit: a backend bug with clear steps, such as duplicates, wrong totals or a race on retry.
• Good fit: a regression with a known "worked in version X" reference.
• Poor fit: a vague report ("checkout feels slow"). Turn it into a measurable target and use best of three.

How do you set up the squad?

Open Squads → New squad, pick Custom and paste the ticket URL in Task link (optional). The field accepts GitHub, GitLab, Linear and Jira links; anything else shows "Use a GitHub, GitLab, Linear or Jira link." Custom starts with one empty member, so add three and write each function yourself.

What objective should you paste?

Restate the bug in a few lines, even with the link attached, and spell out the order of work. Then write Leader instructions: Custom has none by default.

Fix ENG-482: webhook retries create duplicate orders.

What we know
- The payment provider retries order.paid when our endpoint is slow.
- Each retry creates a new order row with the same event id.

Done when
- A regression test sends the same event twice and gets one order.
- Existing order tests pass. No sleeps or retry hacks.
- The report names the root cause in one sentence.

Leader instructions
Reproduce first. Start the fixer only after the reproducer's test fails
for the reason in the ticket. Then send the fix and the test to the
reviewer. If the reviewer asks for changes, send them to the fixer.

What limits should you set?

Set 4 rounds and 3 members at once. The work is mostly sequential, so rounds matter more than parallel slots: one to reproduce and fix, one or two for review feedback, one spare.

Paste your next ticket link into a squad and let it reproduce the bug first.

Get Tallos →

How does the run go?

An example run with a Linear ticket. The ticket, code and diff are illustrative.

1. 1

   The leader reads the ticket

   It opens ENG-482 and plans: reproduce first, then fix, then review.

2. 2

   Reproduce

   The reproducer writes a failing test: the same event id creates two orders.

3. 3

   Fix

   The fixer adds an idempotency key to order creation. The test passes.

4. 4

   Review

   The reviewer approves and suggests a unique database index as a backstop.

5. 5

   A question for you

   Should the unique index ship in this change or in a separate migration? You answer: separate.

6. 6

   Report

   The leader files the report with tallos squad report and the run waits for your review.

What will the leader ask you?

Bug squads ask about scope and facts the ticket left out. The leader asks with tallos squad ask; you pick an option or type your own answer.

• "Add the unique index in this change or in a separate migration?"
• "The ticket's steps don't reproduce it locally. Do you have a sample payload?"
• "Existing duplicates are in production data. Clean them up here or leave it to ops?"

What do you get at the end?

• Final report: root cause, the fix, the regression test and open risks. In the example: order creation had no idempotency key, so each retry created an order; regression test added; unique index left for a separate migration.
• Results by worktree: the fixer's worktree marked Recommended, with View changes.
• Accept or Discard: Accept turns the recommended row into Open to create PR. Link the PR to the ticket as you normally would.

Before you accept, check that the test fails without the fix. Our guide on reviewing AI-generated code covers what else to look at.

What variations work well?

• Two fixers. When the root cause is unclear, set How many to 2 on the fixer and ask the leader to compare, like best of three.
• Skip the reproducer. For a bug that already has a failing test, use build and review with the ticket link.
• Save it once. Save as squad keeps the three roles. Next bug, change only the link and the objective.

What are the common mistakes?

• Pasting only the link. If the agent can't read the ticket, the leader is guessing. Restate the bug in the objective.
• Fixing before reproducing. Without a failing test, you can't tell a fix from a coincidence. Say the order in the leader instructions.
• Allowing symptom patches. Ban sleeps, retries and try/catch-and-ignore in the objective.
• Trusting the ticket blindly. Ticket text becomes part of the leader's context. Read it before you start.

New to squads? Walk through your first squad, see how squads work, or read how the leader talks to Tallos through the Tallos CLI.