Dario Kondratiuk

My ideas used to end up as markdown notes in a folder, which is a polite way of saying they ended up nowhere. Filing a real ticket is more effort than I want to spend in the ten seconds I actually have the idea.

Now I say /new-idea and describe it in a sentence. It interviews me — what's the problem, what does done look like, what's explicitly out of scope — and it stops as soon as the ticket is unambiguous, then files it under my epic and assigns it to me.

At the same time, another session — [on a stable worktree, remember?](https://fab.mabl.com/posts/2026-05-06-dario-i-had-20-worktrees-and-no) — is running /idea-loop. It picks the oldest idea up, moves it to in progress, and we build it: plan, tests, review, PR. From there the ticket walks its own states, and a morning check only marks it shipped once a production tag actually contains the commit.

We already had two tag skills: /can-i-tag tells you if a single repo is ready to ship, /where-is-my-feature traces one feature by keyword across our whole pipeline. Neither answers the question I actually had most mornings — is anything of mine stuck somewhere in that pipeline, and I just don't know it yet. So I asked Claude Code to build /needs-tag, reusing /can-i-tag's tag-lookup logic and /where-is-my-feature's version-comparison logic instead of reinventing either. First real run turned up a merged PR of mine that had never been tagged, plus a downstream repo still running an older version of a shared dependency than it should have been. Neither was catastrophic. Both were things I would have found eventually, on my own, probably days later, probably in a Slack thread that started with someone else asking why something broke.

This week I turned a few of my most experienced teammates — and myself — into AI code-review personas. Each one is built from around a thousand of their real review comments, so it reviews the way they actually do.

Mine was the funniest to write. My number one move in a review, by far, is just asking "Why?" Often the whole review is one word. So that's the first rule in my persona. The AI version of me is, accurately, a single skeptical "why?" on every diff.

The others have their own fingerprints. One is security-first. One reads prompts and tool descriptions as hard as code — "this is a book," "too many tokens." One always asks "don't we already have this?" before you add new code.

Now they run as a gate before I push: each persona reviews in turn and keeps going until it has nothing left to complain about.

The funny part: writing each persona made me see my own habits from the outside. Turns out I really do just ask "why?" a lot.

If you can describe how your best reviewers think, you can get some of that judgment on every change — not just the ones they happen to catch.

I had a handful of PRs open at the same time last week, and the bottleneck wasn't the code — it was me remembering what each session was doing by the time I came back to it. You can't keep a chat window open for every PR. So I wrote a small skill: save dumps the current session to a file keyed by a pull request, and load brings it back when I return to that PR. If one piece of work spans three repos, it's stored once and I can reload it by any of the three PR numbers. When every PR in a memory gets merged, it quietly deletes itself in the background — I'm not going to garbage-collect my own notes. The whole store is local and gitignored, because this is my mess to keep, not the team's.

I plan a change with the agent, it opens a PR, and then I do what everyone does: go to GitHub to actually read the diff. GitHub is still the best place to read code. The problem is the round trip. I'd leave a comment there, switch back to the terminal, and then… what? Tell the agent to go read my comment on line 40? Paste it back myself? That's not reviewing, that's being a courier for my own feedback.

So I started using Hunk (not Hulk — Hunk: https://github.com/modem-dev/hunk). It opens a diff viewer that the agent and I are both looking at. I leave inline comments and the agent reads them right where I left them. No copy-paste, no relaying through chat.

The part I didn't expect: if a Hunk session is open, mauro-reviewer drops its review notes straight into it instead of the chat. So now I don't have to leave the diff to talk to the agent about the diff.

A build fails. Now what? You go to GitHub, stare at a wall of actions, hunt for the red one, open it, and dig around to figure out what actually happened. And if it turns out to be a mabl deployment, you click the link and start all over again inside mabl. Forget about it. Nobody wants to do that.

So I made it stop. I built a github-build-explorer agent that runs on Haiku — cheap and fast, exactly right for digging through logs. It finds the red build and tells you what broke. And if it's a mabl deployment, /mabl-debug kicks in: it pulls the deployment, the failure analysis, the recovery sessions, goes hunting for the cause in the code, and reproduces the failure in a real browser with our new local debugger for agents.

It gets better. You can ask Claude to open the PR, wait for the red, and fix it — all on its own. And the best part: before it pushes anything back, the debugger re-runs the test to confirm it actually fixed the issue. Not "probably fixed." Fixed.

I noticed Claude was building a lot of things I wasn't sure I wanted built yet. The pattern was always the same: I'd type something like "can we make X do Y?" and come back to a plan, a diff, and sometimes a PR description. Which is fine when "can we" really means "do it" — and a problem when I was still figuring out if it was the right move.

So I added a rule to my CLAUDE.md. If a prompt sounds like a suggestion or an open question — "let's do X", "what if we tried Y?", "should we Z?" — Claude has to push back first. Is this the right problem to solve? Is there a simpler approach? What's the downside? Only after I confirm does the model get to write code. Imperative phrasing — "add X", "fix Y", "implement Z" — still goes straight to work.

The first time it triggered I almost edited the rule back out, because the critique was annoying. Then I realized that was the point. I'd been paying for code I hadn't really asked for.

Many of us have been struggling with rate limits lately. I spent part of last weekend thinking about why, and realized something embarrassing: I was using the agent to fix merge conflicts and bump a CLI version into the execution engine. That's not what the agent is for. The honest reason I kept doing it — I had roughly 20 worktrees open and couldn't tell you where the code in terminal five actually lived.

I scaled back to four. Named wt1 through wt4, multi-purpose — I decide what each one is for. They share the same color across my terminal, Chrome tab groups, VSCode, and Finder. Each tab gets a Planner session for feature design, a Terminal for deterministic tasks, and one panel per repo.

I know sub-agents could do something similar. But this is more transparent to me — and a CLI task inside a UI session eats context window, while a UI session in a CLI shell doesn't have the right skills loaded. First day. Maybe it helps someone else too.

I built a code-review subagent and named it after Mauro. This is not a joke about Mauro — Mauro really is our best reviewer. He reads the code with his eyeballs. He suggests an enum every time he sees three magic numbers in a row. He reads the strings inside the code, notices when "Error fetching MauroAgent data" should have been a template literal, and tells you. He won't accept eslint-disable-next-line without a reason. When he sees a prompt he can't follow, he says "if I can't understand it, the LLM won't either."

I wrote those rules down. That was the agent. It took an afternoon.

Mauro's reaction was that I replaced him because I got tired of waiting for his reviews. That part is also true. The interesting thing is how little of his review style I had to invent — most of it was already a list of habits he applies in the same order to every PR. The reviewers we trust most are the ones whose taste is the most legible. Turns out legible taste compiles.

I keep watching Claude reinvent the same shell pipeline three different ways across sessions. Routine cross-repo operations like dependency bumps are the canonical example: an engineer asks Claude to do it, and Claude figures out a slightly different approach each time — usually right, sometimes wrong, always slow.

What I've been pushing for is a shared scripts directory for the things that are deterministic. Bump a CLI version into a downstream repo? Script. Generate a new connector skeleton? Script. Snapshot a runner config? Script. When the work has a known shape, the agent shouldn't be reasoning it out — it should be calling the script. We pay for the agent's reasoning when we need reasoning. We shouldn't pay for it when we just need the right command in the right order. The cleaner the line we draw between "this is a deterministic operation" and "this needs the model," the better the system gets at both.