My current agentic software development workflow

The workflow

I use coding agents every day. Over the last 30 days, Codex recorded 1,490 skill invocations while I worked. Here's what that workflow looks like for me.

Plan while context is fresh

I use Matt Pocock's engineering skills.¹ I start a new app with grill-me. Inside a repo, I use grill-with-docs.

This is where I spend most of my attention. The agent asks one question at a time, and we work through how the feature should behave and the edge cases. After all that planning, the context in that session is gold. We've already worked through the decisions and why we made them, so I use to-spec in the same session to turn that context into a spec while it's still fresh.

I put the spec in GitHub Issues. Linear would work too. Then I use to-tickets to split it into small tickets. Each one describes what needs to work and which other tickets it depends on. Keeping the work small helps me avoid what Dex Horthy calls the "dumb zone", where too much context starts hurting the agent's work.²

One ticket, one session, one worktree

I give each ticket its own session and Git worktree. I point the agent at the ticket and run implement.

The agent writes tests first for the parts we agreed to test and runs type checks as it works. At the end, it runs the full test suite and a separate code-review skill before committing. I add Playwright tests when the ticket involves browser behavior.

Before I call a ticket done, I want a check for every acceptance criterion. Bugs can still slip through, but I want to know what was actually tested.

Shortcuts and UI work

I skip the spec and tickets for small changes. Adding a menu option or fixing a small bug can go straight to implement. If I'm unsure how something should work, I still grill first.

For UI work, I attach a reference image and keep iterating until it looks right. I care a lot about how the app looks and feels, so I check that myself. Playwright checks things like clicks, navigation, and state changes.

Parallel work

I check the dependencies from to-tickets to see what can run at the same time. Each ticket that's ready gets its own session and worktree. Then I start the agents, go AFK, and wait for Codex notifications.

When I run into merge conflicts, I use resolving-merge-conflicts. When the changes are ready, I use the official GitHub plugin's github:yeet skill to check the changes, commit them, push the branch, and open a draft PR.³

Why I rarely read every diff

I rarely read generated code line by line now. I open the app, try the feature, and check that it works the way I wanted. Then I approve the PR and merge it.

Most of my attention goes into the plan before the agent starts coding. By the time I'm trying the feature, it's been through the spec, the ticket's acceptance criteria, tests, and code review. That's what gives me enough confidence to merge.

I still read the relevant code for auth, billing, migrations, and anything that can delete data. I spend more time on those changes because there's more at stake if something goes wrong.

The tools can change

I started with Claude Code and later moved to Codex. The workflow doesn't depend on either one. I need the agent to follow my skill files, work in separate worktrees, run the project's tools, and tell me which checks passed.

I use Cursor's unslop skill for product copy, docs, and PR descriptions. I also use it when an agent's explanation takes too much effort to understand.⁴

Addy Osmani has a similar agent-skills collection that can select skills automatically based on the task.⁵ With Matt's workflow, I call the main skills myself as I move from planning to implementation. I haven't tried Addy's collection yet, but I want to.

I'm still changing how I work with agents. For now, I spend my time figuring out what I want to build, then give each agent a clear ticket and a fresh session.