{"slug": "my-agentic-engineering-workflow", "title": "My Agentic Engineering Workflow", "summary": "A developer shared a workflow for managing multi-repo agentic engineering projects, using worktrees and CLAUDE.md files to coordinate multiple AI agents across different microservices. The approach treats agents like junior developers, giving them tasks with final human sign-off, and relies on a structured directory layout with main branches and feature worktrees.", "body_md": "*Full comparisons and context in my 2026 AI tech stack post. This is just what you need installed to follow the workflow below.*\n\nIf you're new, start with the [cheat sheet](https://awesomeclaude.ai/code-cheatsheet) and [Anthropic best practices](https://code.claude.com/docs/en/best-practices).\n\n**Security — set this up first:**\n\n`.env`\n\nand any `.claude/settings.local.json`\n\nbefore anything else**MCP:**\n\n**Skills:**\n\n`/grill-me`\n\n, `/handoff`\n\n, `/improve-codebase-architecture`\n\n(covered in detail below)`/improve-codebase-architecture`\n\n**Agents:**\n\n**Hooks / proxies:**\n\n**UI:**\n\nAs I've mentioned in previous posts, my workflow is typically very different from what you'll see in the hype and social media posts. I don't typically work on monorepo, single stack, single language projects. My clients are typically full-on microservices with multiple languages and stacks. And beyond that, I still prefer IDEs over fancy pluggable text-editors, which often means I can't keep all the projects single scoped.\n\nWhat this means is that current favourites like [Air](https://air.dev/), [Conductor](https://www.conductor.build/), and [Antigravity](https://antigravity.google/product/antigravity-2) don't work for me.\n\nSo I've been solving my own problems, and this process I'm sharing today allows me to employ multiple agents working mostly independently on different repos towards a singular goal. I treat my agents like I would juniors or contractors; trust but verify. I give them tasks, but I have final sign-off.\n\nThis has been one of the key things I've learned. Let's assume the project has five different repos for different microservices. Some of them are `trunk`\n\nbased, others use `feature`\n\nbranches, it doesn't really matter, but we assume there is a default main branch work always goes back to. I keep these in `~/Source/mains`\n\nso I always have a source of truth to sync with and revert back to.\n\n```\n~/Source/mains/\n├── CLAUDE.md\n├── repoA           <--- frontend\n│   ├── CLAUDE.md\n│   └── README.md\n├── repoB           <--- backend\n│   ├── CLAUDE.md\n│   └── README.md\n├── repoC           <--- backend\n│   ├── CLAUDE.md\n│   └── README.md\n├── repoD           <--- backend\n│   ├── CLAUDE.md\n│   └── README.md\n└── repoE           <--- shared lib\n    ├── CLAUDE.md\n    └── README.md\n```\n\nEach repo has a `CLAUDE.md`\n\nfile that contains the context and instructions for the agent. This is where I can add any specific instructions or context that the agent needs to know. Ideally that references readme as well as any other specs or ADRs that are relevant to the project.\n\nIf you are really lucky, there is a `.understand-anything`\n\nfolder that can be referenced, but regardless, one of the first things I try and add is a CLAUDE.md in the root which ties all the repos and other CLAUDE.md files together.\n\nAlright, so let's assume we have a feature request and we already know that it's going to span multiple repos, so let's say it affects two microservices (B and C) and one shared library (E). I'll start by creating worktrees in `~/Source/worktrees`\n\nfor the feature (call it feat1) with whatever branch name convention the team follows. This allows me to work on multiple features or bugs at the same time without having to worry about conflicts.\n\n```\n~/Source/worktrees/\n└── feat1\n    ├── repoB\n    │   ├── CLAUDE.md\n    │   └── README.md\n    ├── repoC\n    │   ├── CLAUDE.md\n    │   └── README.md\n    └── repoE\n        ├── CLAUDE.md\n        └── README.md\n```\n\nFor example, let's assume there is also a frontend bug fix that needs to happen, which touches repos A and C. I can create another worktree for that feature (call it bugfix1) and work on it in parallel.\n\n```\n~/Source/worktrees/\n├── bugfix1\n│   ├── repoA\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   └── repoC\n│       ├── CLAUDE.md\n│       └── README.md\n└── feat1\n    ├── repoB\n    │   ├── CLAUDE.md\n    │   └── README.md\n    ├── repoC\n    │   ├── CLAUDE.md\n    │   └── README.md\n    └── repoE\n        ├── CLAUDE.md\n        └── README.md\n```\n\nOkay, so pretty boring stuff so far, but here comes the magic. Now that I have all the repos set up in my worktree, I can start planning and coordinating the implementation. For this, I usually start with a new `claude`\n\nsession in the mains directory. Why? Because it has all the context, and if I missed something in my initial assessment, it can tell me what I missed and help me fill in the gaps.\n\nSo I start a new session, switch to Plan Mode (because I use the `/model opusplan`\n\nmode and I want to use the best for planning), and then start with a `/grill-me`\n\nor `/grill-with-docs`\n\nif I have a PRD already, and we bash that out until I'm happy with the proposed plan. But since I don't want this session to handle the work, because it's overloaded by context, I give it the following command instead.\n\n/handoff separate agents will be handling each repo, so create a handoff doc with enough context from the plan for each agent to handle their part independently\n\nThis creates a handoff document that I can copy into `~/Source/worktrees/feat1/handoff.md`\n\nand then use to coordinate the implementation, without overloading the context of each agent's session.\n\nThis next bit is important; I keep the mains session open and do a `/clear`\n\nto start from scratch. This session is my overwatch. It knows the big picture and can coordinate the agents when something comes up.\n\n```\n~/Source/\n├── mains               <---- Overwatch session runs here\n│   ├── CLAUDE.md\n│   ├── repoA\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   ├── repoB\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   ├── repoC\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   ├── repoD\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   └── repoE\n│       ├── CLAUDE.md\n│       └── README.md\n└── worktrees\n    ├── bugfix1\n    │   ├── handoff.md\n    │   ├── repoA\n    │   └── repoC\n    └── feat1\n        ├── handoff.md  <---- generated by overwatch\n        ├── repoB       <---- dev session run here\n        ├── repoC\n        └── repoE\n```\n\nAlright, so with that in mind, let's actually do the thing.\n\nFor this part, it kinda depends on how complicated the implementation is, but generally, I'll start by creating a new `claude`\n\nsession for each repo in the worktree. I will make sure it has permissions to access the handoff file. Then, depending on the complexity, for each agent I'll do one of the following.\n\nFor simple tasks:\n\n/goal you have [repo name], have a look at @handoff.md and determine what to implement, and check yourself against criteria set for you\n\nFor slightly harder tasks, I switch to Plan Mode:\n\nyou have [repo name], have a look at @handoff.md and determine what to implement, and present a plan for me to review. ask questions where you are unsure.\n\nI don't tend to use `/grill-me`\n\nhere again, since we've already done that, and the handoff doc should have all the context we need. Once I have the plan, I check if there is any cross coordination needed between the agents, and if so, I will go back to my main overwatch session, and have it do a review for me, since Claude stores all plans in `~/.claude/plans/`\n\nby default.\n\n```\n~/.claude/plans/\n└── you-are-investigating-the-snuggly-sundae.md\n```\n\ntwo agents are working on [feature we discussed] based on this handover you generated @handoff.md - please review their individual plans and coordinate any cross dependencies. the plans are [@plan_for_repoB.md] and [@plan_for_repoC.md]. update the plan files if needed.\n\nIf there were any updates, I'd go back to the agents and have them review the updates and prompt me again before proceeding in Auto Accept mode, which I'm comfortable with since I've already reviewed the plans and have my Claude setup with various security checks and hooks. Measure twice, cut once.\n\nI won't bore you too much here, because this is highly dependent on the project and the testing strategy. Generally, I'll have the agents run the unit tests and make sure they pass. If there are any issues, I'll go back to the agents and have them fix them.\n\nFor UI things, if Playwright is available, I'll have the agents run using the MCP server, otherwise I just end up testing manually. At the end of the day, I'm still the one responsible for the quality of the code, and I need to make sure it's good before logging my pull/merge request.\n\nThe important bit here is actually when something goes wrong. Because we might have a scenario where both agents need the context of the thing that's broken, for review purposes, I'll actually start a new reviewer session in for example `~/Source/worktrees/feat1`\n\nand tell it\n\ndifferent claude agents implemented the feature in @handoff.md, and we are experiencing [bug or issue]. please investigate and fix it. you have access to all the relevant repos, and you can see their plans @~/.claude/plans/[plan name 1].md and @~/.claude/plans/[plan name 2].md if you need the context.\n\nThis allows me to use a clean slate to investigate the issue, putting us back in the \"good\" part of the context window, and have cross repo coordination in case a change needs to be made in more than one place.\n\n```\n~/Source/worktrees/\n├── bugfix1\n│   ├── repoA\n│   │   ├── CLAUDE.md\n│   │   └── README.md\n│   └── repoC\n│       ├── CLAUDE.md\n│       └── README.md\n└── feat1               <---- reviewer session here\n    ├── handoff.md\n    ├── repoB\n    │   ├── CLAUDE.md\n    │   └── README.md\n    ├── repoC\n    │   ├── CLAUDE.md\n    │   └── README.md\n    └── repoE\n        ├── CLAUDE.md\n        └── README.md\n```\n\nEven if testing went well though, I usually also run this one at least once:\n\nplease review the last git diffs and commits on this repo and compare the implementtion to @handoff.md and highlight anything that might have been missed or not correct\n\nOn a side note, a feature I've been playing with but don't quite have working the way I want is `/loop`\n\n. This is pretty cool, you can run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo). What I've tried doing is having something in the CLAUDE.md of each repo which says\n\n\"If you are stuck and need high level questions answered, put your question in a file called @~/Source/mains/feat1-questions.md.\"\n\nI then, in the overwatch session, have a loop running that checks for new questions and answers them in the same file. When that's done, I can tell the worker agent to look for the answers and continue with its work. I love this idea, but it doesn't quite always work the way I want it to. But still, it's a cool coordination experiment.\n\nIdeally you want just a `/loop 5m look at @~/Source/mains/feat1-questions.md and if your question is answered continue with your work`\n\n... that would be amazing. But alas, no luck getting it working consistently yet.\n\nOkay, damn, that was a wordy blog post. Ultimately for me, it comes down to handling my agents the way I would my humans. If I gave two juniors different repos to work on, I'd make sure to have a mid or senior dev to review their work, and a lead or a PM to coordinate their efforts. Ultimately, all this is a just a manual stopgap until I have [CAST](https://wynandpieters.dev/posts/cast-intro/) [working](https://wynandpieters.dev/posts/cast-first-blood) though.\n\nWhat I also love about this approach is that it doesn't limit me to just using Claude. Any harnass that can have the skills installed, and that have the security bits in place can be used. I can swap out my IDEs and editors, the harness I use, the LLM model, all of that. The process matters more than the tools.\n\nWith that, I hope this gives you some ideas of how you can use Claude Code to be more productive. I'm sure there are better ways to do this, and I'm always looking for feedback and suggestions. I think the closest I've found is probably [Gas Town](https://github.com/gastownhall/gastown) by Steve Yegge, and there is some overlap in the way things are structured. If you have any other suggestions or questions for me, please reach out to me on Twitter or LinkedIn. But in the meantime, happy coding.\n\n*This post was inspired by others, like this one from Harper Reed, as well as from discussions with my teammates at NetNineNine, and from working on CAST.*", "url": "https://wpnews.pro/news/my-agentic-engineering-workflow", "canonical_source": "https://dev.to/wynandpieters/my-agentic-engineering-workflow-2ocm", "published_at": "2026-06-21 12:42:00+00:00", "updated_at": "2026-06-21 13:07:15.774692+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models"], "entities": ["Anthropic", "Claude", "Air", "Conductor", "Antigravity"], "alternates": {"html": "https://wpnews.pro/news/my-agentic-engineering-workflow", "markdown": "https://wpnews.pro/news/my-agentic-engineering-workflow.md", "text": "https://wpnews.pro/news/my-agentic-engineering-workflow.txt", "jsonld": "https://wpnews.pro/news/my-agentic-engineering-workflow.jsonld"}}