How my AI workflow evolved from prompts to workflow

About six months ago, my AI workflow was already useful.

I had reusable commands. I had predefined templates. I had a decent setup in Cursor and later Claude Code and Codex. It was enough to make AI generate code faster, help me plan, and reduce some repeated prompting. That was already a big step up from starting every session from scratch.

But after using it every day, I noticed that the biggest problem in my workflow was no longer code generation.

It was me.

I was still the one remembering what command to run next. I was still the one dragging context from one step to another. I was still the one making sure the AI did not skip verification, drift from the requirement, or quietly move too fast into implementation.

In other words, the AI could generate decent code, but I was still doing too much of the workflow orchestration myself.

That is the part that changed the most for me over the last six months while building and dogfooding AI DevKit.

The old workflow: reusable, but still manual

Six months ago, my main idea was simple: make prompting more reusable.

Instead of rewriting the same long instructions again and again, I created reusable commands and predefined templates. That helped a lot. I could kick off requirement writing faster. I could structure planning better. I could avoid some of the prompt fatigue that happens when you keep repeating yourself in every new project.

It worked, but it still felt like a power user setup, not a real workflow system.

The commands were reusable, but they still needed me to manually invoke them at the right time. The templates were helpful, but they still depended on me to connect the dots between requirement, design, implementation, and review. If I was tired or moving too fast, the workflow could still become inconsistent.

The system was better than raw prompting but it just was not carrying enough of the burden yet.

What changed in the last six months

That is where the newer version of AI DevKit feels different.

The evolution was not just adding more commands. It was moving from commands and templates into skills, memory, auto-triggered behavior, and automatic verification.

That shift sounds small on paper. In daily use, it changed a lot.

• Skills made the workflow more reusable at the right level of abstraction. Instead of only saving a prompt, I could package a way of working.
• Memory helped the system carry forward context that I had already established before, so I did not need to keep restating the same engineering preferences or workflow rules.
• Auto skill triggering reduced the need for me to remember exactly when to push the next step.
• Auto verification made it harder for the process to silently skip the boring but important parts.

That is the real upgrade. My current workflow is better at carrying context, verifying work, and keeping me from repeating myself.

Recent development with AI DevKit

A recent feature in AI DevKit made that difference very obvious to me.

I was building interactive skill selection for ai-devkit skill add.

For the context, previously, if you wanted to add a skill with ai-devkit CLI, you needed to know the exact skill name. If you did not know what was available in a registry, you had to search first, then copy the name, then run the add command. It worked, but it was clunky. Two steps when one should be enough.

The feature itself was small. If the user runs ai-devkit skill add <registry> without a skill name, the CLI should show an interactive multi-select list so they can choose what to install.

I opened Codex and gave one sentence of instruction.

$dev-lifecycle new requirement: when user install skill ai-devkit s kill add <registry> but no skill name define, we will display an interactive selection for user to select the skill to install, the list of selection will be extract from the registry

From there, the dev-lifecycle skill took over and moved through the phases: requirement, review requirement, review design, execute plan, update planning, check implementation, write tests, and code review.

A few months ago, I could have built the same feature with reusable commands and templates. But I would still be the one manually stitching the process together. I would need to remember which command came next, decide when to review, decide when to verify, and keep the workflow aligned in my head.

Now the workflow itself carries more of that load.

The system pulled in a memory I had stored earlier about CLI commands needing a non-interactive fallback for CI environments. I did not have to remember that rule in the moment. It was already there. It became part of the requirement conversation automatically.

That sounds small, but this is exactly the kind of thing that gets lost in normal AI sessions.

Then it scaffolded requirement, design, and planning docs. It created the artifacts that support the code.

Then it reviewed its own requirement output. Then it reviewed the design against the requirement. Then, during implementation, it updated the planning progress as tasks were completed. Then it checked the implementation back against the requirement and design. Then it wrote tests against the requirement, not just against the implementation.

What feels more convenient now

The convenience is not only that the AI writes code for me.

The convenience is that I do not have to keep pushing the workflow forward manually.

• I do not have to remember every next move.
• I do not have to restate every important rule.
• I do not have to rely on discipline alone to make verification happen.

The workflow is becoming much better at carrying its own structure.

The whole session took under 30 mins from ideas to PR. For a feature that produced requirements, design, planning, implementation, verification, tests, and review artifacts, that still feels a bit wild to me. The artifact of this feature can be found on GitHub.

What still needs me

That does not mean it replaces judgment.

I still made product decisions during the implementation. I decided to keep the first version simple. I chose not to over-design the selection UI. I decided when a flat list was good enough for v1. The workflow drove the process, but I still drove the product and the tradeoffs.

I do not want AI to pretend to be a product engineer making judgment calls it does not understand. I want it to handle more of the repetitive engineering workflow around me so I can spend more time on the decisions that actually need me.

That is also why automatic verification matters so much.

Without verification, AI workflows feel productive right until they are not. The code looks ok. The output feels fast. Then later you realize the implementation drifted from the requirement, skipped an edge case, or quietly missed something obvious.

I have become more convinced that the real value in AI-assisted engineering is not just code generation. It is workflow discipline made easier to sustain.

That is what I have been trying to push AI DevKit toward over the last six months.

Try it yourself

If you want to test this workflow yourself, here is the easiest way to start.

The fastest way to get the full setup is with the engineer template, then run one command to install the dev-lifecycle skill, verify, tdd, debug, and everything else I use daily:

npx ai-devkit@latest init -t engineer.yaml

That engineer.yaml looks like this:

environments:
  - cursor
  - claude
  - codex
phases:
  - requirements
  - design
  - planning
  - implementation
  - testing
skills:
  - registry: codeaholicguy/ai-devkit
    skill: dev-lifecycle
  - registry: codeaholicguy/ai-devkit
    skill: debug
  - registry: codeaholicguy/ai-devkit
    skill: verify
  - registry: codeaholicguy/ai-devkit
    skill: tdd
  - registry: codeaholicguy/ai-devkit
    skill: memory
  - registry: codeaholicguy/ai-devkit
    skill: capture-knowledge
  - registry: codeaholicguy/ai-devkit
    skill: simplify-implementation
  - registry: codeaholicguy/ai-devkit
    skill: technical-writer

One command, all three agents (Claude Code, Codex, and Cursor) are configured, all skills installed.

Then open your favorite agent (Claude Code, Cursor, or Codex), then type: “Use dev-lifecycle skill to build [your feature].” Watch what happens.

The code is open source: github.com/codeaholicguy/ai-devkit

Docs: ai-devkit.com

Closing

Six months ago, I was mainly optimizing how to talk to the model better.

Now I care more about giving the model a workflow that can carry context forward, reuse proven skills, trigger the right behavior automatically, and verify work before I trust it too much.

A workflow system that stays useful across Cursor, Claude Code, Codex, and any other Coding Agent. Reduce the amount of repeated orchestration I need to do myself.

I still review the code and make the important decisions, and it is clearly better than where I started.

For me, that is the real evolution.

If your current AI workflow mostly helps you write code, but still makes you carry too much of the process in your head, that is exactly the gap I have been trying to close with AI DevKit.

If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.