Sharing my agentic workflow: open sourcing devloop

I’m open sourcing devloop, a plugin for Claude Code and Codex that packages how I want coding agents to approach development.

These are skills I use daily in my own development work, and I’m constantly refining them as I learn what works and where the instructions fall short.

The philosophy behind devloop reflects how I’ve approached software development for a long time, shaped in large part by Out of the Tar Pit, a paper by Ben Moseley and Peter Marks.

Coding agents make this philosophy even more relevant. They make it easier to add code, but every addition is something we take responsibility for maintaining. Even when an agent does the maintenance, we still pay for it.

Not all code is technical debt, but unnecessary complexity becomes debt we’ll have to pay down with time, extra loops, and more tokens, or keep working around.

My deliberately exaggerated reading of the paper is:

State is the root of all complexity.

That’s my emphasis, not the paper’s exact claim. The authors describe state as “the single biggest remaining cause of complexity in most contemporary large systems.” They also discuss control flow and code volume, and clarify that by state they generally mean mutable state. The paper is worth reading.

What sticks with me is how much work comes with storing something. Someone has to own it. Changes have to reach the right places. Transitions have to remain valid. Two representations of the same fact can disagree, and now the system needs code to reconcile them.

A value that could have been derived becomes something we have to keep correct.

Take a list of selected items and a separately stored selection count. Every path that changes the selection now has to update the count too. Deriving the count from the list removes that obligation. Storing it might still make sense if counting is expensive enough, but that tradeoff needs a reason.

Some complexity belongs to the problem. Some comes from our design choices. Some additional complexity is justified by performance or other requirements. I want an agent to make those distinctions and question what we’re taking on.

Where skills help

Skills give me a place to write down how I want recurring development tasks approached: what context to read, which assumptions to challenge, and what to report back. I can inspect those instructions, version them, and refine them when they produce a poor result.

That is useful when a short request hides a lot of judgment. “Implement this issue” might require checking whether part of it has already shipped. “Review this PR” should include questioning the design, even when the tests pass. A skill makes those expectations explicit without having to repeat them in every prompt.

Devloop currently includes three independently useful skills: start-work, deep-review, and adopt. They run through the agent’s existing tools in the project. The instructions guide its judgment; tests and CI still provide the executable checks.

Deep review

I use deep-review when there is a concrete change to examine: a PR, branch, file, or commit range. For example, I can ask it to review a PR that introduces a cache and check whether the performance need justifies the extra state and invalidation logic.

The central instruction is:

Make sure every change earns its place without introducing accidental complexity.

Correctness matters: regressions, broken contracts, invalid states, and unintended behavior changes. The review also asks whether the complexity a change introduces is necessary and justified.

Does this abstraction help enough to earn its maintenance cost? Does this flag represent a real requirement? Could we remove or simplify something while still meeting the specification and preserving expected behavior?

State gets particular attention: what must be stored, what can be derived, who owns it, and which transitions are valid. But it shouldn’t dominate every review. The skill also considers consistency, abstractions, and whether a change fits the current design or a clearly justified future direction.

It reviews first, then proposes fixes, without editing files in either phase. I decide which findings to act on before asking for implementation. Those proposals get challenged too. A smaller diff can still leave us with a worse design.

Start work

start-work brings similar care to the beginning of a task. I use it when I have an issue or task that I want the agent to investigate and implement. It grew out of a skill I already use in another project.

It takes an issue, ticket, or task description, checks it against the current code and recent decisions, and investigates before committing to a plan. Once the scope is clear, it prepares the branch and proceeds into implementation and verification.

Small tasks get a brief plan in the session. For larger work, the evolving plan and decisions live in the draft PR by default. If the project already has a place for plans, it uses that and links it from the PR. The point is to give the next session somewhere reliable to continue.

For example, an old issue might ask for a new API when a merged PR has already added most of it. The useful first step is to find the remaining gap and adjust the scope. An issue can become stale. A plan can outlive the assumptions behind it. I want the agent to notice that before building on them.

Adopt the practices

Some instructions matter throughout the work. I want the agent to question unnecessary complexity while implementing, and to investigate a failed fix before trying another one.

I use adopt when setting up or refreshing the instructions I want agents to follow across tasks in a repository. It copies selected engineering practices into the project’s AGENTS.md. The current catalog covers design judgment, debugging discipline, test design, writing style, commit conventions, and handoffs. You can choose individual practices or adopt all of them.

The debugging guidance is a good example: a failed fix is evidence that the agent’s understanding is incomplete. Repeated guesses shouldn’t become an excuse to rewrite the feature. Read the dependency’s source, narrow the hypothesis, and find out what would disprove it before editing again.

These are opinionated starting points you can adapt to your project. Re-running adopt updates older, untouched sections and asks before replacing local customizations. It leaves the rest of the file alone.

How the skills fit together

On a larger task, the useful loop is implementation, review, and revision. Review findings inform the next changes, which are verified and reviewed again. adopt sits alongside that work: its output is project guidance that later sessions read.

flowchart TD
    accTitle: How devloop skills support a development task
    accDescr: Start-work investigates and implements a task. Deep-review reports findings and proposes fixes. Changes are applied, verified, and reviewed again as needed before merging. Adopt installs project guidance used during implementation and review.
    work["start-work<br/>Investigate, scope, implement, and verify"] --> review["deep-review<br/>Findings and proposed fixes"]
    review -->|Changes needed| revise["Apply changes and verify"]
    revise --> review
    review -->|Ready to merge| merge["Merge when checks pass"]
    guidance["adopt<br/>Install practices in AGENTS.md"] -.->|Project guidance| work
    guidance -.->|Project guidance| review

Updating the guidance is a separate decision when a lesson is worth carrying into future tasks. You can use deep-review on a PR you wrote yourself, or adopt one practice without using the other skills.

Where this is going

Longer term, I want devloop to grow into my own adaptation of Anthropic’s AI-native SDLC playbook. I wrote about the shift behind it in From What Code to Write to What to Build: as implementation gets faster, more of our attention moves toward choosing the problem, setting the scope, and deciding whether the result is useful.

For now, I’m starting with the skills and practices I already use. Devloop is heavily focused on GitHub, with issues, branches, and pull requests carrying the work and the context needed to continue it.

I’ve always wanted a balance between process and productivity. Enough structure to make good decisions and preserve context, with overhead that makes sense for the work.

Anthropic’s playbook approaches the AI-native SDLC largely through the needs of teams in larger organizations: coordinating specialized roles, managing handoffs, and maintaining governance.

With devloop, I want to adapt that development loop for solo building. The same person chooses the problem, works with the agent, reviews the result, and maintains what ships. I want a process that helps me carry intent from one stage to the next, learn from what goes wrong, and improve the next iteration, with overhead that fits one person doing the work.

I’m also interested in which approaches hold up across different scales. Clear intent, useful verification, and decisions that survive a session are valuable whether you’re working alone or with a team. I want to explore those common foundations as devloop develops.

The process itself should meet the same standard as the code: every addition has to earn its place.

Devloop is public here, with installation instructions for Claude Code and Codex. Both use the same plugin package, with each application managing its own installation and updates. Try it on a task or PR, adopt the practices that fit your project, and tell me where the instructions fall short.