This is my three phase development approach. I start with some inputs — a ticket, a requirement, an idea, whatever — and end with implementation. In between, there is structure. The phases look like this: design, implementation, ship.
Phase One: Design #
This is the most important one, so I will spend most of the time here.
Design phase is where I literally put and shape the context the agent will work in. When there is a ticket, or a half-formed idea, that becomes the input. I drop it in and then we talk.
The key part: I ask the agent to challenge me. This is very similar to Matt Pocock’s grill-me skill, but in most cases I do not even need a skill for it. I just ask the agent to push back and answer questions back and forth. What about this case? Did you think about that? Why this and not that? We go back and forth like this until the solution holds together.
Once I am more or less okay with where we landed, I move on. And this is important — it is not a separate step or a separate session. Same session, same context. I just say “okay, we are good now, go implement.”
Phase Two: Implementation #
This is a regular coding session. Nothing fancy.
If something is wrong, I ask the agent to fix it. Sometimes the thing that is wrong is not the code, it is the design — so I return back to the design phase and we re-design. Then back to implementation. Sometimes I am totally okay and implementation is just good.
One important part of this phase is to have some level of definition of done in your context. For me, “implement” means implement — and that includes testing, and all the rest of it. I do not want to spell that out every time. So I keep the definition of done somewhere the agent can see it — in AGENTS.md
, or somewhere else it will read. That way “go implement” already means “and write the tests, and make it actually work,” without me repeating it.
Phase Three: Ship #
Last phase, and the most different one, because it is much less interactive.
In most of my repositories I have a skill called ship
. It is different for each repo — each one defines its own specifics — but the shape is the same. It is fast: format the pull request to the formal requirements of that repo, then babysit until CI is green. Then a security review. Then babysit again until that is green too.
If the repository allows it, I do automatic merge, again with some requirements attached. And after that, the same ship skill tends to do post-merge checks. This part matters more than people think. If you are shipping a site, merging to main triggers work — a deploy, a pipeline, something. So my ship skills check the after: main CI is green, the application actually deployed, that kind of thing. Shipping is not “merged,” shipping is “live and confirmed.”
You can see this in practice — the ship skill in everruns and the one in bashkit.
That Is It #
Three phases. Design, implementation, ship. Design is where I challenge and get challenged, implementation is a regular session against a clear definition of done, ship is the less-interactive part that babysits the thing all the way to live.
Most of the value is in phase one. The other two are just making sure the good idea actually lands.
One side note: on repos that are not configured — no ship skill, no conventions of their own — I lean on a generic-development skill that defines my terms, so I can speak the same vocabulary everywhere. Supportive, not a phase.
For comments or feedback, write atx.com/chaliy.