My agentic coding workflow, a year later

It's been almost 12 months since I wrote up my Claude Code setup, and a lot has changed. I'm no longer only in Claude Code. I move between Claude Code, Codex, and Pi throughout the day, and herdr is what holds it all together. I just published a new post on what's changed, what's stayed the same, and what I've learned along the way.

One idea from it I want to pull out here: shaping is not plan mode. Plan mode helps an agent figure out how to implement a solution. Shaping makes sure we understand the problem well before anyone gets to the how. When the work is well shaped, I rarely reach for plan mode anymore.

For shaping, I use Matt Pocock's grill-with-docs skill. It interviews you about a plan, and it writes down the decisions and the terms you define as you go, so future agents get that context too. Here's a trimmed excerpt from a recent session where I was shaping an artifacts feature for Praxis:

❓ Q1 - Who views artifacts in v1: Is v1 for you alone, viewed through the private admin gallery over Tailscale, with client-facing sharing deferred to a later phase? The alternative is building share links and a public origin from the start, which pulls in the Cloudflare repo and a token model on day one.

➡️ Yes. You only, admin gallery, Tailscale. Client sharing is a later phase.

❓ Q4 - Kinds in v1: Only html and design-system in v1? No markdown rendering, no React build step, no slides type.

➡️ Yes. Two kinds. Markdown waits until something needs it.

Those two answers settle scope before any code gets written, and they already keep an agent from building a share-link system nobody asked for. From there I turn the session into a spec and a set of small issues with my spec-writer and issue-writer skills, and hand each issue to a fresh agent.

If you want to learn more about this process and the rest of my development loop, including how I build with pstack, review with specialist agents, and ship, the full post walks through all of it.

Read the full post: My Agentic Coding Workflow →

How I ship an epic as small PRs

When I hand an agent a whole epic, I get a lot of change back, and one giant pull request is hard to review well. So my agents ship the work as GitHub stacked pull requests instead.

In a stack, each pull request holds one focused change and builds on the one below it. The bottom PR targets main, every PR above it targets the branch below, and a reviewer only sees the diff for that layer. Each issue from the shaping step becomes one pull request, a vertical slice that ships with its own tests, and the stack follows the blocking relations between issues. The rule is that if one layer depends on another, the dependency has to live in the same branch or a lower one, so a slice that's blocked by another sits above it. Tests that exercise the whole thing can sit in a slice on top. The gh stack CLI extension handles the fiddly parts, like rebasing everything above a fix to a lower layer, or cleaning up with gh stack sync --prune once the bottom PR merges.

A few things to know before you try it. Stacked pull requests may not be enabled for your repository yet, in which case gh stack exits with a "not enabled for this repository" error. Every branch has to live in the same repo, GitHub Desktop doesn't support them, and the PRs have to merge from the bottom up. You can restructure a stack after the fact, but it's a process: gh stack modify lets you drop, fold, insert, or reorder branches, and then you run gh stack submit to recreate the stack on GitHub. It's worth getting the order of the slices right up front.

GitHub also ships an official gh-stack skill that teaches an agent the commands, so you don't have to write your own. Install it with:

gh skill install github/gh-stack

claude-code-workflows is now agent-skills

I also released an update to my skills library this week. It started life as claude-code-workflows, and I've since merged it with my older agent-skills repo, so everything now lives in one place at dgalarza/agent-skills. The split between the two repos had blurred, and which install path a skill used came down to where it happened to land instead of what it did. stacked-prs is part of a new engineering-skills bundle alongside team-code-review, conventional-commits, conventional-comments, and tdd.

One heads up if you installed from the old Claude Code marketplace: it was renamed from dgalarza-workflows to dgalarza-agent-skills, so your existing install ids will stop resolving. Re-add the marketplace and reinstall:

/plugin marketplace add dgalarza/agent-skills
/plugin install codebase-readiness@dgalarza-agent-skills

I also removed a handful of skills I no longer use. They stay on your machine if you have them, but they won't get updates. The post has the full list.

Read the release post →

Quick Hits

• Erin Galarza's first public bot template. It's called Winnie 🗓️, and she handles the household appointment juggle: medical, dental, school, and personal care. She books online when she can and calls the office when she can't. What I like is that the template starts from how the errand actually gets done, not from what's easiest to automate.

How are you handling review when an agent hands you an epic's worth of changes? Hit reply and tell me. I'm curious whether anyone else has landed on stacks.

If you're working out how to adopt this kind of workflow across your team, from shaping work for agents to the review loops that keep them reliable, that's the kind of engagement I take on. Here's how I help →

Damian