Dominik Drąg

Devflow

A Claude Code plugin I wrote for taking a feature through exploration, architecture, implementation, testing and review. It is open source.

An earlier project. I no longer use or actively maintain Devflow. My current workflows are in DD Skills.

  1. Explore. Discovery, with agents exploring the codebase.
  2. Clarify. Claude Code asks questions; you answer them.
  3. Design. An architecture you approve.
  4. Plan. An implementation plan you approve.
  5. Implement. The change itself.
  6. Verify. Tests and an agent quality review, then your approval.
  • Your answers and approvals (the workflow waits)
  • Claude Code and its specialized agents

A diagram of the /feature workflow, simplified, not a recording. Stage lengths are not to scale. Drag across the lanes to scrub.

Structure for the work around the code

A feature begins before its first line of code. There is an existing system to understand, a problem to clarify and a design decision to make. The result also needs tests, review and an explanation of what changed.

Devflow puts those activities into an explicit workflow for Claude Code. It gives each phase a purpose and creates decision points before work moves on.

The problem it addresses

A coding agent can produce a plausible implementation while still working with an incomplete picture. If exploration, design and verification are implicit, it becomes harder to see which assumptions shaped the change.

Devflow makes the path visible. Specialized agents support exploration and review, while explicit approval points keep material choices with the person directing the work.

A workflow with decision points

The standard feature workflow begins with discovery and codebase exploration, then asks clarifying questions. Architecture design and planning happen before implementation. Tests and a quality review follow the change.

The repository also provides a test-first workflow, architecture-only exploration and standalone reviews. This lets the amount of process fit the task.

What to inspect

  • The /feature command for the main implementation workflow.
  • The /tdd command for a test-first approach.
  • The documented architecture, plan and review approval points.
  • The guidance on when a full workflow adds unnecessary overhead.

The trade-off

More explicit steps create more opportunities to catch a misunderstanding, but they also take time. The README recommends skipping full workflows for trivial changes, urgent hotfixes and exploratory prototypes.

The right amount of structure depends on uncertainty and the cost of a mistake. A workflow is useful when its checkpoints help someone make a better decision.

Source and limits

The public repository documents the tool’s design and workflow. This article is based on its README; it does not report measured productivity gains, adoption or commercial results.

Explore Devflow on GitHub

Source: Devflow README, checked . My current workflows are in DD Skills.

Tell me about your project

Say what you’re working on and where it’s stuck. I reply within two working days.

Prefer email? hello@dominikdrag.com

Topic

Used only to reply to you.