Building out our task workflow

I’m Daniel, a Senior Engineer at Gondola. We build software for customs clearance, which means a misfiled declaration is not a cosmetic bug, and the rules shift by country and by commodity code. That matters for what follows. We work in a domain full of conventions that only make sense here, and a tool that reviews our code without knowing them is only ever half useful.

Most of our engineering runs through Claude Code, Anthropic’s agentic coding tool. You give it a task in your terminal and it reads the codebase, makes the change, runs the tests and reports back. On top of that we run superpowers, an open source workflow plugin that gives Claude Code a process: brainstorm the spec, plan the work, implement, review.

Superpowers was well thought out when we adopted it and it handles the overall shape of the work well. It does reviews too, but it is deliberately not opinionated about any particular stack, so its judgements stay general. It will tell you a function is too long. It will not tell you that we don’t do it that way here.

The dull part

Pull request review was the part of the week I liked least. Days of it. Being a lazy and efficient engineer, I did the obvious thing and asked Claude Code to review the PR and fix whatever it found.

That worked well enough that I did it again on the next one, and the next. After a few rounds I was retyping the same instructions about the same things, which is usually a sign that a prompt wants to be a skill. So I built one. deep pr reviewer knows what to look for in our codebase specifically, and fixes what it finds.

The harder question was how to improve it without having to think up every rule myself. We already had GitHub Copilot reviewing our PRs, so I set up a loop. Copilot reviews after our skill has had its pass, and anything Copilot catches that we missed gets folded back into the skill. It isn’t reinforcement learning in any technical sense. It is a cheap signal about our own blind spots, applied by hand.

N+1 queries came out of that loop early. The first version of the skill didn’t look for them at all. It read a diff the way a careful person reads a diff, line by line, and an N+1 rarely announces itself on any single line. Copilot flagged them, we taught the skill what the pattern looks like in our code, and it has caught them since.

Borrowing other people’s opinions

Around this time I came across the Nuwa skill on social media. Nuwa distills a person into a skill. You give it someone’s published writing and talks, and you get a reviewer that argues from their perspective.

That seemed useful for review. A linter tells you something is wrong. An opinionated engineer tells you it’s wrong and why they wouldn’t have built it that way to begin with. So I built review lenses from the public writing of five people I trust in different directions: Justin Searls on testing and code health, Kim Goodwin and Luke Wroblewski on interaction and interface design, Andrew Knight on test automation, and Gergely Orosz on engineering practice more broadly. To be clear about what these are, they’re personas assembled from published material, not the people themselves.

The value is the spread. A change to a data grid gets read by something that cares about query patterns and by something that cares about whether the interaction still makes sense to the broker using it. That mix is the kind of feedback a good senior reviewer gives and a linter never will.

From skill to agent

Eventually the skill got good enough at finding its own problems that Copilot mostly stopped having anything to add. If the reviewer no longer needed babysitting, it didn’t need to be something I invoked by hand in the foreground. It could be an agent running in the background that any task could call when it wanted a review.

So I converted it. Ask for a deep PR review and it goes off, finds issues, fixes them. Running it repeatedly turned out to matter, because new fixes sometimes introduce new problems, so looping until only nits come back became its default mode. It usually takes three to five passes to settle.

A review used to be days of work, most of it spent checking a change against conventions that live in our heads and in scattered corners of the codebase. Now it’s a rough skim of the diff. The convention checking has already happened several times over and I can be reasonably confident the code is right. The human pass gets to do the thing people are better at anyway, which is asking whether this was the right change to make.

The SOP

Then I read an article on Red Note about someone implementing a Standard Operating Procedure skill, and it clicked.

I served in the Singapore Armed Forces from 2001 to 2009. SOPs are how everything there works. You don’t simply use a weapon. There is a documented procedure for using it, stripping it and cleaning it, written down so it happens the same way every time regardless of who is doing it. A live firing at the range isn’t “go and shoot” either. You organise the range, brief your subordinates, and announce that live firing is about to commence so anyone nearby clears the area, and only then does the first round go downrange. The procedure exists so the outcome doesn’t depend on anyone’s memory or mood that day.

I had been running the same unwritten procedure on every task for weeks, so I wrote it down as a skill:

1. Pick up a task from the task list or board
2. Do proper discovery, across web, codebase and ticket, to build context around the task
3. Use the superpowers brainstorm to produce the spec and the plan
4. Implement
5. Run static analysis and the test suite, and address what comes back
6. Run the multi lens review, meaning our deep PR reviewer plus the distilled expert perspectives
7. Wrap up the workflow

Now I can say “Look into GH issue 12345 with the SOP skill” and it will create a worktree for the work, build its own understanding of the task, fan out background searches in parallel to fill in context, and carry on through the rest of the flow.

Where it fell over

On simple tasks this worked straight away. On big features it didn’t.

The problem was structural. The multi lens review sits at step 6, right at the end, so when it surfaced something major, something that should have changed the design, the finding had nowhere to go. The plan was already built and implemented against. The brainstorm at step 3 had no expert input at all, so the sharpest opinions in the system were only ever consulted after every decision had been made.

The symptom was usually over-engineering, or quiet drift from what was asked for. One implementation turned every column in a data grid into its own separately loaded HTML partial, which is defensible if you squint and far more machinery than the problem needed. Another exposed a field through the API that accepts floats, where the underlying value is an integer and always has been. You don’t catch either of those by reading the diff line by line. You catch them with something that looks at the shape of the solution and asks why we’re doing it this way at all, and at step 6, with the feature already built, that question arrives too late.

So after a week or two on the simple version I changed it. Major findings in review now loop back into re-discovery and re-planning instead of dead-ending in a comment. And there’s a phase after the brainstorm where the distilled experts weigh in on the spec and the plan, before any code exists.

That got it running the way we wanted. Implementation is now largely hands off.

What this does to the job

Less time writing the change, much more time defining the task precisely enough to be worth handing over, then reviewing and testing what comes back. The work has moved closer to product management than it used to be.

It also means the work isn’t confined to engineers. Adam has shipped real pieces through this workflow: several proof of concepts that we went on to adopt or rework, and the DTR piece for NZ Customs, which is his end to end. A shipped integration against a customs authority, built by someone outside the engineering team.

We don’t all watch the same things, though. José, Gondola’s founding engineer, and I were talking about this in the car recently and landed in different places. I still like the investigation itself, the narrowing down, the moment the cause finally shows itself. He isn’t especially concerned with how the agent got to an answer. What he watches is the shape of the solution and the architecture, and his pushbacks are usually the same one: the agent has fixed something confusing instead of refactoring to make it less confusing first. That is a better instinct than mine for this way of working. Automating the tedious parts of the job also automates some of the parts that were quietly the reward, and it moves your attention to where it now counts, which is the design rather than the diagnosis. Worth being clear that we’re making that trade.

Where we’re going

There’s more room to let non-engineers produce working implementations and that’s the direction we’re pushing. The caveat matters as much as the direction. Whatever your agents produce still has to survive your own review and your own testing. The judgement doesn’t go away, it moves from writing the code to specifying the work and checking the result. In an industry where a wrong number on a declaration has consequences, that isn’t a step we want to skip.