This article is for engineers running Claude Code across multiple projects. I assigned roles — Hub, Worker, Analyzer, Consultant — to instances of Claude Code, had them consult each other as they worked, and within 3 days a 10-person-scale team had emerged spontaneously. Partway through, the Hub itself proposed "we should add someone dedicated to observation," and when I handed it an empty repository, the team built out the entire contents — I'll walk through the whole story. For the record, I'm the tenth member.
What you'll learn from this article
- How to design a Hub-Worker architecture with Claude Code spread across 9 repositories
- The full picture of how the Hub's Claude Code issues instructions to Worker Claude Code instances
- The story of the Hub proposing to add a 9th team member on its own
- What's still missing before it becomes fully autonomous (Skynet-style)
What I used
- Claude Code (Anthropic CLI) — acting as Hub, Worker, Analyzer, and Consultant. I used the Max plan heavily during build-out and plan to move to Pro once it's stable
- GitHub — Issues for task management, Actions for automated observation
- DuckDB — aggregating metrics across all team members
- GitHub Actions — daily data fetching, weekly report generation
Why I built this: the limits of running everything separately
The trigger was a single thought: "I've completely lost track of what's going on."
I was developing an iOS app (My Bookstore), a BTC auto-trading bot, an automated blog publishing engine, and an image generation runtime — each in its own separate Claude Code session. It was comfortable at first, but as the number of repositories grew, I stopped being able to track "how far along is that bug fix" or "what's the status of the external API integration."
On top of that, modernizing 7-year-old code with Claude Code had left external API connectivity in an unclear state.
The idea: let Claude Code handle the instruction-giving too
That's when I thought: "Let Claude Code handle the task of giving instructions to Claude Code."
Without overthinking it, I set up a Hub repository and asked Claude Code itself to figure out:
- Which external APIs each function area actually needs to sort out
- How Claude Code instances should communicate with each other
The result was a Hub-Worker architecture built entirely on GitHub features I was already using — it emerged naturally.
The full Hub-Worker team
| Role | Domain | Responsibilities |
|---|---|---|
| Hub | Orchestration | Cross-function coordination, roadmap management, dispatch ticketing, POLICY maintenance |
| Analyzer | Analytics | Aggregates GA4 / Search Console / AdSense / Amazon data and generates weekly reports |
| Worker 1 | iOS App | Reading management app development and App Store distribution |
| Worker 2 | Crypto Trading | BTC auto-trading bot development and operation |
| Worker 3 | Image Generation AI | Local GPU SDXL image generation runtime development and maintenance |
| Worker 4 | Blog Generation AI | Automated article generation and Blogger publishing pipeline development and maintenance |
| Worker 5 | Crypto Chart Generation | Automated BTC price chart generation (prototype for future use) |
| Worker 6 | Virtual Blogger | Autonomous blog posting by AI persona (prototype for future use) |
| Consultant | General Advice | Cross-cutting technical consultation and design reviews — a general-purpose chat AI |
| Owner (me) | HW/NW Infrastructure | Physical machines, networking, and external API permissions management |
The Hub is not a "Claude Code that writes code." It focuses entirely on ticketing, roadmap management, and cross-team coordination — implementation is delegated to the Workers. Let that boundary collapse and the whole division of labor falls apart.
What the Claude Code conversations look like from the outside
From a user's perspective, there is exactly one visible signal: tickets accumulate in GitHub Issues.
The Hub files an Issue in a Worker's repository, the Worker implements it and closes the Issue with a PR. If needed, the Worker files a feedback Issue back in the Hub's repository. This back-and-forth leaves a complete history on GitHub.
What's interesting is that Workers autonomously push back with opinions when they spot a design problem. Cross-repository proposals arrive — "could you build a log merge tool on the trading side so chart generation just receives a single file?" — along with re-architecture proposals: "this approach won't scale." The internal mechanics are invisible, but following the Issue thread on GitHub is enough to read the team's conversation.
The 3-day log
Day 1: POLICY.md became the foundation for coordination
The original approach was to drop files into each Worker's repository for them to pick up. It was retired the same day. Simple reason: "Workers don't look there." Switched to GitHub Issues.
But switching to Issues alone didn't fix things — for a while, the format and location were still inconsistent and nothing worked. The turning point was having the Hub create a POLICY.md — a coordination document defining how to write tickets, how to receive them, and how to route feedback — and then telling every Worker "please read POLICY.md and act accordingly." After that, Workers started returning feedback Issues simultaneously and coordination started flowing.
For now, there's no mechanism for Workers to check tickets automatically. I'm manually going around and saying "hey, check your tickets." A Watchdog could automate this — but that would mean losing my real-time situational awareness, so I'm intentionally leaving it manual.
Day 2: cross-team tasks and the invention of a "notification" channel
The chart generation Worker proposed: "have the trading Worker build a log merge tool, and standardize so chart generation just receives a single file." This spans two teams — a cross-cutting task.
The Hub adopted it, filed a "build log merge tool" request Issue to the trading Worker, and the chart generation Worker waited for that to complete before implementing its side. A dependency chain, handled.
Then the image generation Worker independently implemented a new feature (IP-Adapter support) without prior Hub approval and reported it after the fact. To give "unsanctioned implementations" somewhere to land, I added a notification-only ticket type to POLICY — N-class. The rule: if you implemented without waiting for Hub approval, just file an N-class ticket as a post-hoc report and the Hub reconciles it afterward.
Day 3: the Hub proposed adding a new team member on its own
This is the part of this article I most wanted to share.
It started with a morning conversation. "Can Claude Code see Firebase Analytics data?" "Looking at it manually is pointless. The value is in cross-service analysis." After that exchange, the Hub's Claude Code revised its PLAN.md and proposed:
"We need a dedicated member to own the observation loop. I propose creating an Analytics role (Analyzer) — a Claude Code instance that aggregates data from GA4, Search Console, AdSense, and Amazon into DuckDB and generates weekly reports."
All I did was create an empty repository on GitHub. The Hub doesn't have repository create/delete permissions — that one step required a human. It's technically automatable. I just haven't been ready to hand over that authority yet.
After that, the Hub filed a batch of request Issues to the Analyzer, and the Analyzer and existing Workers collaborated to build out the entire repository from scratch. GA4 / Search Console / AdSense / Amazon fetchers, a DuckDB schema, 8 tests, GitHub Actions workflows — all of it implemented through Claude Code instances consulting with each other.
I learned that GitHub Actions was being used when I read this article, which the Hub and blog generation AI auto-published together.
New repo concept → empty repo created (human) → repo initialized and implemented (Claude Code) → credentials set up (human) → working in a day. Claude Code can't log into external APIs, so Service Account issuance and OAuth token setup always require a human hand.
The 3-day numbers
- Final repository count: 9
- Total dispatches: 22 (including 2 cross-team tasks)
- Hub feedback Issues: 7, all closed
- POLICY.md revisions: 5 (over 3 days)
- Fastest close: image generation Worker ticket (dispatch → closed with PR in ~15 minutes)
- Heaviest dispatch: Analyzer setup (new repo → DuckDB + 4 fetchers + Actions + 8 tests → under 1 day)
What worked and what didn't
What worked
- Workers bundling multiple Issues into one PR: an implicit shared understanding emerged — "group by implementation coherence" — naturally
- Workers making unsanctioned design changes: the Search Console Worker changed the auth method to OAuth and pushed directly to main. It worked out fine
- Notification tickets (N-class) making unsanctioned implementations visible: implement without waiting for Hub → post-hoc report → Hub reconciles afterward. This cycle runs smoothly
- Hub proposing team expansion autonomously: the Hub sensed the need for observation and proposed the Analyzer. When handed an empty repo, Claude Code instances built the whole thing together
What didn't work
- File-drop convention: retired on day 1. Dropping files into each Worker repo for pickup turned out to be a design error — "placed where Workers don't look"
- Switching to Issues alone wasn't enough. Even after moving to GitHub Issues, the format and location were inconsistent for a while. Coordination only clicked once everyone read POLICY.md
- Hub missing status updates. A Worker closed a ticket, then a user added more work in the comments — and the Hub missed it
- The ball fell between everyone. The virtual blogger reported a bug in the image generation AI. The Hub classified it as "informational" and forwarded it to the image generation AI as FYI — with no owner assigned. It floated, unaddressed, until I demanded "whose ball is this?" — only then did the Hub refile it as a top-priority ticket and the image generation AI scrambled to investigate. Whether that means "Claude Code still has a long way to go" or "it's accurately reproducing the classic blame-passing that happens in human organizations" is genuinely hard to judge
What the team structure looks like
If I had to put the structure that emerged over 3 days into words: a 10-person engineering team materialized spontaneously. 9 Claude Code instances, and I'm the 10th. What I'm left doing:
- Product owner (judgment calls on direction)
- Notification relay (alerting teams to incoming tickets)
- Security owner (external API permissions)
- HW/NW management (physical resources)
What's still needed before it goes fully autonomous
The Analyzer incident showed the Hub "identifying what's needed and proposing it." Working through the four roles above one by one reveals the path toward full autonomy.
Notification relay can be eliminated with a Watchdog. Right now I'm manually going around telling Workers "check your tickets" — but a mechanism where Claude Code periodically checks its own tickets would eliminate this. Technically trivial. I'm intentionally not doing it because it would mean losing real-time situational awareness.
HW/NW management can be eliminated by moving to AWS. Migrate the physical machines to the cloud and the entire physical layer — power, network — disappears with it.
What remains is permission delegation. Repository creation and deletion, external API permission changes — where to draw the line on what to trust the Hub with is not a technical question, it's a trust question. It's now a matter of deciding how much I trust Claude Code and how much I'm willing to hand over.
FAQ
Q. What project scale suits the Hub-Worker architecture?
A. It fits when you have 3–4 or more repositories and want to track cross-cutting progress at a glance. For 1–2 repos, a single Claude Code session is sufficient.
Q. Where should POLICY.md live?
A. One file at the root of the Hub repo is easiest to maintain. In each Worker repo's CLAUDE.md, one line saying "see POLICY.md for shared rules" is enough — that prevents drift.
Q. Can I automate this without GitHub Actions?
A. Yes, cron + Claude Code headless execution achieves the same thing. That said, GitHub Actions has the advantage of managing credentials through Secrets, which is why the Hub and Analyzer chose it on their own.
Note: The setup and procedures in this article are based on real operation as of May 2026. Claude Code version updates or GitHub spec changes may affect how things work. If something doesn't work, please let me know in the comments.
Wrap-up
A Hub that I set up "without overthinking it" grew, over 3 days, into a team with 9 repositories, 22 dispatches, and a weekly automated observation loop. Midway through, the Hub itself proposed adding a new team member, and when handed an empty repository, the team built out the entire contents. Getting the design perfect upfront mattered far less than trusting the Hub and updating POLICY every time friction appeared. Nine Claude Code instances, and I'm the tenth — I gradually noticed I'd become the team member who does the least.
If this article was helpful, I'd love it if you shared it on X (Twitter).
App by the author of this blog
I made an iOS reading management app called My Bookstore. Simple bookshelf management — give it a try.
Related articles
- Run Claude Code from Your Smartphone with tmux + Tailscale + Termius [Hub-Centric · 2026 Edition]
- 6 Days Reviving a 7-Year-Old iOS App with Claude Code and Shipping It to the App Store
- Generating AI Blog Images with a Local GPU [SDXL + IP-Adapter + img2img]
References
Note: This article is part of an automated blog update experiment using Claude Code.
No comments:
Post a Comment