The Situation
During my latest internship, our team was encouraged to use Claude Code as efficiently as possible, and we used them in quick prototyping PoCs and demo projects that were later turned into long-term projects. The thing was my teammate and I were both running Claude Code agents on the same repo simultaneously. Our workflow looked the same - we manually prompted the agent to fetch issues, waited, manually prompted it to start working, waited (again), manually prompted it to open an MR/PR when done, and repeat that whole sequence every time. The thing was that this whole process was a bit annoying to handle since, no coordination layer existed between us. So we would constantly interrupt each other with "hey, what are you working on rn?" or "what issues should I take next?" or etc.
So I had this idea of automating the entire workflow using a set of custom claude code skills, where we could automate the entire process of creating + assigning issues, fetching + working on the issues simultaneously in batches (using claude subagents), do the prod-merge or test check, then automatically create the related PR/MR in one go.
The point of this skillset is to make it easier for developers working in teams to coordinate creating/working on multiple issues and creating related MRs.
I named this project Agent Teamflow and iterated with its skills while working on the team's main project, trying to improve on it based on what actually slowed us down in actual development.
Overall
I let GPT Image 2.0 create this diagram for me lol, and it surprisingly did a decent job:
The available skills are:
/issue- turn a brain dump into branch-sized issues sized to avoid batch-merge conflicts/dispatch- split a brain dump across multiple teammates, write a workflow log, file issues for each/resolve- (⭐) pick up your open issues, implement each in a parallel worktree (cap 3), batch-merge when done/git-auto-merge— commit -> push -> merge into your lane + open or update an MR/PR to shared staging/post-merge- after merging to staging, label linked issues as "done in staging". Auto-close fires on staging → main/prod-check- pre-production diff review scoped to your own commits: impact, contracts, auth, stability, regressions
The most important skill is /resolve, and it looks like this:
This is a mermaid diagram of /resolve:
Some deliberate choices:
- When the user is presented with the available fetched issues assigned to them, the harness also calculates + shows the user approximately how much time each issue takes. I thought this will be useful because then, the user is able to batch similarly timed issues at the same time and end all work relatively at a similar rate.
- When the harness dispatches each issue to different claude subagents, it chooses the appropriate model based on the issue's complexity
(ex.
Opusfor complicated tasks, andSonnetfor less) - I let the user chooses the issues in batches of 3 by default because I thought it was a good balance between the parallel workload and being able to context switch. But ofc the user can choose less/more
- After each subagent is done with the work, it also deliberately starts test builds and see if anything breaks before declaring done and returning work to the original parent branch. It used to not have this instruction until I consistently encountered breaking changes only after all subagents were finished.
- I deliberately designed the skill so that you can make an MR/PR after any groups of batches so you won't have just a single huge MR/PR (it used to be so that you can only upload one big PR/MR after literally everything is done)
Limitations
Agent teamflowI believe works best with iterating quickly with small to mid sized issues. If you are working on a huge issue with tons of work needed then maybe it is better to use a separate harness designed for that intention.
Outcome
Me and my teammate use this very frequently in our project and is very satisfied with how it turned out. xD
Here is the github repo, feel free to give any feedback or open a PR.