We let agents run the boring half of our projects. They ask better questions than we did

How a small team built an agentic workflow for the point where a project stops being talked about and starts being built.

Every project has two halves. First the meetings: workshops, specs, Lucidcharts, Confluence pages, a lot of talking. That half is fine. Many people can be in the room, and talking is how you get to agreement.

Then someone has to turn the agreed thing into tickets, and someone has to turn the tickets into code. From that moment on, everything has to be specific. A spec can say "the seller should be notified". Code cannot.

What happens in that gap is that things slow down, or the quality drops, or both. A developer sits there with questions about whether they are implementing it correctly, or misses the questions completely. If the questions are never asked, the developer implements what they think is correct based on potentially very vague specs, and we end up with a worse product.

That is where projects go wrong, in my experience. Not in the meetings. In the gap between agreed and specific. In our workflow the developer is at least made aware of the shortcomings and can return to the project team for clarification. That takes time. But we make sure the decisions are logged and specced correctly afterwards.

Humans are not consistent in that gap. Everyone writes tickets differently, even with a template. Everyone explores the codebase differently, implements differently and misses different things.

About three months ago I started building an agentic workflow around Claude Code to close that gap. The original idea was to help project management from a tech point of view. I normally run our projects from the tech side: breakdown sessions, holding the whole spec in my head, pushing back on the PO when something does not add up. Along the way it also became the way our developers pick up a ticket and ship it.

Start with the interview, not the code

The first skill was /feature. It is an adaptation of the well-known grill-me skill by Matt Pocock. It asks you relentlessly about open decisions or conflicts related to the feature you want to build. One question at a time, until nothing is open.

It is amazing at filtering out bad ideas. It surfaces real bugs and open questions that I or my team members never thought about.

Our tickets are written in breakdown sessions and are usually a few lines, almost never well defined enough to start on immediately. So /feature matched our low-effort ticket-writing skills perfectly. Not the AI kind of skills.

Open a session, call /feature, answer the questions, and it writes the spec. Every decision goes in with the answer chosen, so the agent that builds it has nothing left to guess. An incomplete ticket used to become incomplete code, and the difference showed up in review or in production. Now it shows up as a question, before anyone writes a line.

The questions are rarely big. Is a rule symmetric between buyer and seller? Does a guard also apply after a partial refund? Small things that a developer would decide alone at the keyboard, and that the PO would have answered differently. When I cannot answer, I stop there and ask the project team for a decision. In the meantime I work on something else. The workflow allows for this, you just change context and pick up something that is hopefully more specced.

From one skill to a pipeline

After using that for a while I wanted a more hands-off approach. That became /jira.

The idea was a normal research, plan, implement flow. Almost any half-serious AI developer knows about it and it works wonders. The skill takes a GU-xxxx ticket, runs the /feature interview in the main session, and hands the spec to subagents. The interview has to run in the main window, because a subagent cannot ask the user questions.

Two things I added on top of the standard flow:

• Git worktrees. Each ticket gets its own worktree and branch. That way I can run several sessions on different tasks around the codebase at the same time.
• A review loop. Implementation, then review, then implementation again, until the author approves. Every round spawns a fresh implementer and a fresh reviewer, so neither carries the last round's assumptions. It catches things here and there.

We implement tasks differently, and that is one of the fun things about software development. There are multiple ways to a good solution. Given concrete instructions, the agents help us keep the code good and maintainable. The developer is still in the loop, but acting more as an orchestrator than before. There are fun things in this too.

The run ends with a draft PR through /create-pr, the least interesting skill and one of the most used. It enforces our PR template, with one section that matters: "What did we do and why", written for the reviewer only.

The project that forced the next step

A few team members started using the flow and it took off pretty quickly. At the same time we were, and still are, in a rather large project. One large Lucidchart defines the user stories and technical flows. Six Confluence pages span everything from meeting summaries to the release plan, the migration strategy and edge cases.

I was the main technical oversight on that project. Every morning I wanted answers to the same questions. What happened in the last 24 hours? Have the specs been updated, and by whom? Is there something we need to push back on to the PO? What can we spec now and break down?

Those questions are what move a project along. And one more that people rarely ask: what does the code do that the specs don't? Every answer to that is a decision someone took in the gap and never wrote down. We wanted version 1 specs that still held the truth of the system when version 2 starts.

Copy the specs into something an AI can read, then keep them synced

That became /breakdown. It is the heaviest skill we have. The logic is simple though: copy the specs into a folder an AI can read, and keep that folder synced with the sources.

Every run snapshots each Confluence page, Lucidchart and Figma link, and diffs it against the last snapshot. So the morning report says what changed and who changed it. Conflicts and open questions go in an append-only log. Decisions do not go there. A decision is a spec update, so it goes back into Confluence and the log records that the question closed.

One rule was there from the beginning: the folder holds no opinion. I never wanted the codebase to hold specs that were actually the source of truth. If a spec and the folder disagree, the spec wins, silently. That is also why it is so relentless about picking at conflicts between the code and the specs. Say every email says "5 hverdage" and the spec says "1-5 bankdage". If we actually want "1-5 bankdage", then the spec needs to say that, not the code. So it keeps saying: make the PO update this spec so it is the source of truth.

The initial run took a long time and around 700k tokens, and it found conflicts we had to fix right away. After that first sync, each run only reads what changed.

Getting rid of breakdown sessions

Let me be honest about why it is called "breakdown". The motivating factor was the desire to be better at breakdown sessions, or completely get rid of them.

Breakdown sessions are long, tedious and mentally straining. You try to hold every spec in your head while you break down one part of the system. We did the initial round in this project ourselves: two to three hour sessions, once or twice a day, for a week.

So now I write:

/breakdown - Let's break down the sikkerhandel email specs written in x, y and z Confluence pages.

It syncs the project first. Then it explores the code and comes back with what it thinks are the correct Jira tickets, with labels, story points and "blocked by" links. I approve once. It creates the tickets and logs the decisions.

Each ticket is drafted by a smaller sibling of /feature called /ticket. It runs a light exploration agent, enough to land a decent description for /jira to pick up later. Every ticket comes out in the same shape.

In that project, this did around 70% of our tasks, and it did them pretty well.

I can also ask: "After the latest sync, are there any tickets that don't match anymore?" It checks every ticket under the epic against the specs. Each time I ran it, it found tasks that had gone stale, luckily before anyone started on them. Before this, we would honestly just miss those and build against old specs, then fix it later.

The morning

The last skill is /standup. It pulls my open PRs and review requests, my Jira issues that are not done, the local worktrees and the project folders, and reconciles them. Every mismatch gets flagged, like a ticket still in To Do while its branch has commits, or a Jira comment where I asked for a decision and never got one. Then it offers to fix the drift in one go.

The flow today

1. Run /breakdown on a project or an area of it. Answer a few questions, approve the tickets.
2. Run /jira GU-xxxx on a ticket. It goes deep into the details and asks you relentlessly about the feature.
3. When that is settled, it builds, reviews and loops until you approve.
4. Look at the PR, get it ready, merge.
5. Run /standup the next morning.

Where a human sits

The workflow stops for a person at three points, the same three every time:

• The /feature interview. A human answers every open design decision before any code.
• The /breakdown approval. Nothing is written to Jira without a yes.
• The review loop. It ends when the author says so.

Everything else runs without asking.

The critical parts of a project, in what I would call the implementation phase, are few. First, agreeing on an overall technical direction. I might have an idea for this as the primus motor of the project, but it is a team decision, and usually without AI involvement. Then breaking the project down into tickets. How good those tickets are can skew or alter the direction of the whole project. At least it did a lot before we had help.

The last critical part is one we have not talked about: testing. We spend a lot of time on it. We have no QA, our project team are our testers, and we sometimes have a hard time saying what can actually be tested and when. The breakdown skill helps with clarifying that.

Bringing in the team

The developer flow was easy to hand over. /jira asks you questions and you answer them. /breakdown was different. The first teammate to use it got confused and hit a few problems before it clicked. Then they were surprised at the value it offered.

None of this is specific to Claude Code

The skills are Markdown files with instructions. The ideas work with any agent tool:

• Interview before implementation. Every open decision goes to a human before the agent builds anything.
• Open questions go to their owner. The agent finds them and sends them to the PO. It does not answer them.
• One way to write a ticket, one way to implement. Same shape and depth every time, regardless of who asked.
• Specs in a folder the agent can diff. Snapshot the sources each run, and let the source win every time.
• One approval gate per irreversible action. Writing to Jira, pushing to a shared repo, opening a PR.

If you build only one of these, build the /feature skill first, or grill-me. It is a great asset and feels like a tech lead interviewing you. Then build a breakdown skill that helps you break down specs and keeps them in sync. Keep it in another repository, sync daily while specs are changing, and make tickets uniform so the agents have an easier time understanding scope, specs and codebase.

AI knows code and it knows your codebase, so make working with agents great there first. But quickly get a holistic view. The end result is only as good as the entire process from start to finish. There is a reason so much time is spent defining projects, goals and desired outcomes, and it is wrong not to look at that process in tandem with the development team.

Build something that makes your teams work better together. Make sure their understanding of the project does not drift apart through 1:1 meetings, developers chatting over the monitor and making decisions, or a project team not understanding the complexity beneath the system they are responsible for. Being a PO or PM is not only about building new things, it is about integrating into existing complex systems. This workflow helps with those communication issues. This was ours, at least a somewhat modified version 1.