TLDR: Skill, skill, skill. Too many skills. Poor management. Need a better tool. Built the tool. No more managing workflows with skills. Tool makes sure the workflow gets done. Scroll down until you see " Came after TLDR? " to check the core of the post. A typical story of agentic development adoption (or not so typical?). LLMs cannot write code better than me. That’s hype. Hmm, Claude did understand this complex algorithm in my legacy spaghetti project. What if I ask it to implement a feature in it? Ah, interesting. It did it, and it works. Ok, I will give it a try. Ok, it seems it can work in a way. “Stop putting your authorship note in the commit message.” I’m tired of asking it. I will make a skill. Ah, a skill works really well. I will make a skill for checking a Jira description too. And one for publishing changes to Jira. And also one for moving a Jira ticket to a different status. A tailored code-review skill. A skill to publish release notes. (I know, it should be automated in pipelines, but who gives a damn when LLMs & agents are fun to play with.) A skill for implementing a typical API integration. For investigating the scope of development. A skill for this, a skill for that. Skill, skill, skill. Some things moved to slash commands. Some moved back to skills. AGENTS.md, CLAUDE.md, BMAD, get-shit-done (I know), native Claude workflows. Other agents. Ah, Codex is not bad. Gemini is behind (was). Antigravity looks interesting. Switching between different agents. Different models, levels of reasoning, effort. Hermes, local models, herdr. The harness grows. Basically, the whole SDLC is implemented via skills/slash commands. Every part is a separate file: develop, review, test, check-pull-request, reply-to-pull-request, etc. Hm, I would like to manage the whole SDLC pipeline with one command and just leave it running. Ok, an umbrella skill covering all the separate parts looks good. Now, I want to launch development tasks in parallel. Git worktrees have never been in such demand. Hmm, I want to let agents run tests with separate databases, install dependencies, all automatically, so this becomes truly parallel development. Lots of custom shell scripting to manage “worktrees and agentic dev environments”. I’m tired of confirming all those “Can I run this command?” prompts. y, y, y, y, y, … Voilà, a sandboxed Docker container. Here you go, Claude, you can dangerously skip permissions now. OK, I can relax. Or so I thought. But my SDLC pipeline is sometimes overkill for small tasks. I will make another one, “SDLC-light”. It doesn’t spawn so many agents, uses lower reasoning, and skips some steps. Hmm, there is a need for an SDLC in between: “SDLC-medium”. OK, copy/paste, adapt. I also want to maintain documentation, keep track of the state of tasks, record every step, and have the possibility to resume. All done. My slash commands and skills have superpowers now. Wait, where was that part about updating documentation? Ah, it’s in that skill. Ah, it’s also here. I need more pipeline types besides my SDLC, SDLC-light, and SDLC-medium. I will copy one of them and adapt it. Shared files, a locking mechanism, code-map documents, some state moved to a Git submodule. These are just examples of features I have in my harness. I was at the point (and I still am) where my harness was well-developed. I could (and still can) run multiple development tasks in parallel. All truly parallel, in their own branches, worktrees, with their own DB copies, isolated tests, and isolated Docker containers. All corresponding to my needs and to my usual way of working without agents. But. Can I easily share that harness with the rest of the team? No, because not everyone works the same way. Can I transfer this to another project with another team? No, because I don’t have a proper way of moving this locomotive. Can I even easily reuse it for another project where only I am working? Also no, because a lot of shell scripts tailored to the project’s needs are included. And even if I invented a way (I can move my skills/commands to a global scope and reuse them, right?), every project still has its own watchouts & gotchas, so it’s not that simple. Not to mention the cost of adapting those pipelines, the risks of duplication, and the list goes on. I took a break. Just continued using it (it still works for me; I am quite effective with this harness). And in the meantime, I was just thinking. How can I improve this and solve the issue of sharing the workflow, easily adjusting it, tailoring it to specific needs, without carrying around a massive directory of skills/commands? An idea. An agent. An agent with its own workflow syntax. Where I can describe what I want, which specific steps to perform. It can call other agents, whichever ones I want. For architecture? Use Claude. For development? Use Codex. All described in a “workflow” file. Runs automatically. Well, this sounded interesting, but for a solo developer, building such a tool, competing with Anthropic and OpenAI with their really well-developed agents, didn’t seem realistic. Too many gotchas and limitations. Too many unknowns, and too little time. And alternatives exist anyway: OpenCode, Hermes, Herdr, … Came after TLDR? Continue here. What if I do it differently? What if I build a “runtime” that gets executed inside an agent? Or better to say, by an agent. And not just a set of .md files, but with a real backend engine behind it. This sounds viable. And I think I have time to play & experiment with it. First prototype: OK, many bugs & bottlenecks, but it did follow my flow, eventually. Improve: now better. Improve again: good, it follows my workflow as I have defined it. Try to develop more features, but every time it becomes a bit more difficult. The architecture. Time to refactor. Split the tool into 3 logical stages: parsing & validation, building an AST, and delegating to the execution layer. All separate, with their own boundaries, input-output. Great, now it has become much easier to maintain. Develop, improve, test, roll back, adapt, improve. Repeat. Again, architecture. Refactoring. Handlers? Move them to a separate layer so it becomes possible to add more of them easily. And so on. The development loop continues. Eventually, I was able to replace my existing pipelines based on skills, slash commands, and bash scripts. My skills are now doing what they should do: describing craftsmanship. How to develop this? How to write module X? How to write a test following the conventions of this project? The skills not managing my pipeline anymore. This is how I came to develop a fully separate CLI tool: “ww” (agentic workflows). What is the idea behind it? I like to describe it as: structure, state machine, and flow control. You define your workflows in a workflows.yaml file. Every workflow has a strict syntax. Rules and validation apply. Every workflow has a set of steps: research, develop, run-tests, review. And so on, and so forth. You decide about the steps. It’s not just workflows with steps. There are concepts like “modes” (“economy” mode tells it to use as few words as possible), “handlers” (basically, a reusable set of instructions), “hooks” (e.g., “after step ‘develop’ is done, run git-commit”). The tool can execute shell commands (which is important, because you can safely delegate a sensitive task to the ww-runtime, and not to the agent). It supports complex structures: conditional execution of steps based on reasoning results, splitting work into items, performing loops, and launching a UI-based page to control execution. It supports settings for spawning agents with different models/reasoning levels, and so on. Its design is not to execute the agents, but to instruct them instead. The agent understands that it has to work with “ww” via CLI, and ww manages the execution state. ww understands which step the flow is currently at and instructs the agent to perform a certain task. The agent does its job, performs the reasoning, changes code, and hands control back to “ww”. It validates the handoff and proceeds to the next step by giving the agent new instructions. EOL is when the last step is finalized by ww. And it solves my previous issues: I can easily transfer the workflow(s), I can adjust them globally/locally, and I can tailor them to specific needs here and there. One of its most effective parts is that it is agent-agnostic. I’ve tested it myself with Claude Code, Codex, Gemini, and Antigravity, and all of them followed the workflow as intended. I can interrupt the flow in the middle, switch to another agent, and it will pick up where it left off. I have finally released it in beta. Still lots of plans & ideas on the roadmap. I am actively developing it, but the overall approach & syntax are more or less settled. Mostly, new features & refactoring are planned. I use it personally on 3 different projects with Claude Code & Codex. Next week, I will begin adapting it to other teams/projects at the company I work for. A few ideas that will come next: parallel steps, debug/report mode, auto-learning & auto-improvement of workflows, a TUI app, an external DB-based provider to store task state, and updating workflow plans once they begin. Lots of ideas. After that long intro, now, I think I can post a link: https://agenticworkflows.dev/ and https://github.com/from-developers-for-developers/agentic-workflows/tree/main A really small example, just to show, how a workflow might look like: https://github.com/from-developers-for-developers/agentic-workflows/blob/main/workflows.yaml (a real workflow I use for developing ww itself). It is minimalistic, but it is enough. In another commercial project, my workflows are much more sophisticated, with different agent-profiles, steps described more verbose, using external skills, different settings of models/reasoning, etc. For me, personally, it’s a big shift in the way I apply agentic development. I am really enthusiastic about adopting it in other projects, and I hope this can be useful for other developers. This is open source, and stays so. Anyway, I’m happy to receive any feedback, tests, or reviews. Especially from people struggling/doubting in their current workflows. submitted by /u/dmitrya2e
Originally posted by u/dmitrya2e on r/ClaudeCode