Every now and then I’ll run a deep audit on a codebase—sit down, go through everything systematically, and surface whatever needs fixing. The problem isn’t finding the issues. The problem is what comes after.
You end up with a list. Fifteen, twenty things. Maybe more. Some are critical. Some are minor. Some depend on each other. And now you need a coding agent to work through them without losing track, without missing quality gates, without fixing something it wasn’t supposed to touch.
Handing an agent a flat list of “here are 15 things to fix” doesn’t work. It either races through them superficially, gets confused by interdependencies, or—worst case—runs out of context halfway through and you can’t tell what actually got done.
So I changed how I structure this work.
Step One: Let the Agent Create the Items
The first thing I do after an audit is give the agent a short prompt and let it structure the work itself:
Now write individual /queuestack items for the findings
(reference any relevant files) — split if workload for one
item is too much! Then write a master item that references
all sub-items.
Prefix the title of the master item with "MASTER: ".
That’s basically it. The agent reads its own findings, decides on a reasonable granularity for the sub-items, creates them in queuestack, and then writes a master item that references everything.
The master item it creates follows a template I’ve settled on over time: a brief overview, then findings grouped by priority (P0 through P3), then a suggested implementation order, then rules for each item.
## P0 — Critical (fix first)
- [ ] `0XYQTE2` — Sanitization missing in input pipeline
- [ ] `0XYNVT3` — Scoring function returns constant — ranking broken
## P1 — Medium
- [ ] `0XYM9SJ` — Duplicate queries on every request
- [ ] `0XYWW0C` — Two subsystems interact incorrectly
## Suggested Order
Phase 1 — Sequential:
0XYQTE2 sanitization fix
0XYNVT3 scoring fix (depends on 0XYQTE2)
Phase 2 — Can parallel:
0XYM9SJ (independent)
0XYWW0C (depends on 0XYM9SJ conceptually)
## Rules for Each Item
1. Read the individual queuestack item for the detailed checklist
2. Run full quality gate before marking done
3. Update CHANGELOG.md under [Unreleased]
4. Write tests alongside implementation — not after
Ten minutes of the agent’s time. You get a structured work queue ready to execute.
Why Priority Tiers Matter
Not all bugs are equal, and the ordering isn’t just about which ones are worse—it’s about which ones need to go first because later work depends on them.
P0 items are the critical ones. They run sequentially, because if one fix changes something that another fix sits on top of, you can’t parallelize them safely. Everything else can be worked in parallel where the items are independent of each other. The “suggested order” section in the master item makes this explicit. It’s not for me—I know the reasoning, I wrote the prompt that generated it. It’s for the agent that will execute the work.
Step Two: Hand Off to an Orchestrator
Once the master item exists, execution is another short prompt:
You are the orchestrator of /queuestack master item {ID}.
Spawn subagents sequentially for each subitem. That is
essential to avoid interference, as we work and commit
on the main branch and will not use worktrees. After each
subitem is done and the subagent handed off with a green
quality gate, close the subitem and check off the subitem
in the master item. Then commit.
Provide the subagents with sufficient project context
(inject AGENTS.md).
The orchestrator reads the master item, picks up the first open sub-item, spawns a subagent with the right context, waits for it to come back with a passing quality gate, closes the item, checks it off in the master, commits, and moves to the next one.
Sequential by default. That’s the important part. Running parallel agents on the same branch without worktrees is asking for merge conflicts. The orchestrator pattern sidesteps this by never letting two agents touch the same codebase at the same time.
The Per-Item Rules Are the Contract
Each sub-item has a rules section. It’s short—four lines, usually—but it’s binding. The subagent doesn’t close an item without running the full quality gate. It doesn’t mark something done and then run tests. Tests run first. Gate passes, item closes.
This means I can trust the closed items. If it’s closed, the gate passed. If the gate failed, the item is still open. That’s a useful invariant when you have fifteen things in flight.
The Between-Sessions Benefit
Here’s what actually makes this work across multiple days: the state persists.
I can stop mid-audit, come back the next morning, and immediately know where things stand. Open items in the master list tell me what’s left. Closed items tell me what’s done. The git log has commits that reference queuestack IDs—so I can always trace which commit closed which item and why.
git log --oneline
# a2f5689 fix: use rowid-based deletion (0XZ2H7P)
# 3982b21 fix: close sanitization vulnerability (0XYQTE2)
# 8c6ed59 fix: restore scoring function (0XYNVT3)
If I need to pick up in a new agent session, I just point it at the master item ID. It reads what’s closed, what’s open, what the suggested order says, and continues from there. No re-briefing. No reconstructing context I already captured. The item files are the context.
What I Actually Do vs. What the Agent Does
My job in this workflow: run the audit, kick off the “create master item” prompt, review the output, then kick off the orchestrator prompt.
The agent’s job: create structured items from the findings, execute them in priority order, enforce quality gates, close completed items, commit.
That division feels right. The judgment calls—what’s critical, what can wait, what the quality gate should be—are exactly where I want to stay in the loop. The implementation is where I’m happy to step back.
If you’re doing agentic development and running into the “big batch of tasks” problem, queuestack is available at queuestack.app—there’s a macOS GUI version there as well. Or grab it via Homebrew if you prefer:
brew tap domzilla/tap
brew install queuestack
The repo is at github.com/domzilla/queuestack. I covered the basics in an earlier post—this picks up where that one left off.