diff --git a/website/blog/2026-05-08-worktree-trick-multi-project-ai-teams.md b/website/blog/2026-05-08-worktree-trick-multi-project-ai-teams.md new file mode 100644 index 0000000..7dd53fa --- /dev/null +++ b/website/blog/2026-05-08-worktree-trick-multi-project-ai-teams.md @@ -0,0 +1,247 @@ +--- +slug: /2026-05-08-worktree-trick-multi-project-ai-teams +canonical_url: https://dfberry.github.io/blog/2026-05-08-worktree-trick-multi-project-ai-teams +custom_edit_url: null +sidebar_label: "2026.05.08 Worktree Trick" +title: "The Worktree Trick: How I Run 40 AI Agents Across 8 Projects Without Losing My Mind" +description: "Two months of failed experiments taught me that the best way to manage multi-project AI agent teams is the oldest tool in git's toolbox — worktrees — paired with a centralized hub." +draft: true +tags: + - AI Agents + - Git Worktrees + - Squad + - Developer Experience + - AI-assisted +keywords: + - git worktrees + - ai agents + - multi-project management + - copilot cli + - squad framework + - developer productivity +--- + +# The Worktree Trick: How I Run 40 AI Agents Across 8 Projects Without Losing My Mind + + + +![PNW river delta metaphor — one main channel splitting into distributaries representing worktrees](media/2026-05-08-worktree-trick-multi-project-ai-teams/pnw-river-delta-hub-worktrees.png) + +I stopped asking the AI to manage workspace state.That's the whole trick. + +For two months I tried architecturally ambitious approaches — unified squads, per-project squads, sub-coordinators, distributed skill systems — all trying to teach LLMs how to switch branches, route work, and stay on task. None of it worked reliably. Here's what I discovered: the thing that actually solved it was removing that burden entirely. I create a git worktree *before* I launch Copilot CLI. One command, in my regular terminal. The session starts already in the right place, with the right branch, and no decisions left to make about where to work. + +This post covers three layers: the problem I hit (multi-project chaos), the approaches I tried and abandoned, and the architecture I landed on. Let me walk through how I got here. + +## What I'm working with + +If you're running more than a few AI agents, you'll hit the same coordination wall I did. Understanding the scale helps explain why the simple solutions broke first. + +I'm a senior content developer at Microsoft. I manage documentation and tooling across 8 active projects, 20+ repos, and a [Squad](https://github.com/bradygaster/squad) team of 40+ AI agents — PMs, engineers, adversarial reviewers, fact-checkers. The agents have names like Harper-pm-data and Casey-pm-content-repos and Ferris-eng-rust, because when you have 40 agents, "Avery" means absolutely nothing. (I stole this naming convention from how ops teams name microservices — more on that later.) + +The hub repo is called `project-dina`. It's the single brain for everything — one `squad.agent.md`, one `decisions.md`, one shared skill library. Physical repo clones live flat under `./repos/`. A file called `repos.json` maps each repo to its project, its auth method, its PM agent, and its sweep config. Think of it as a routing table for work. + +Getting to this architecture took three attempts and two failed experiments. My perspective: the failures taught me more than the solution did. + + + +![Flowchart showing progression from same-directory approach through per-project squads to hub plus worktrees solution](media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.png) + +## Approach 1: Put everything in one directory(Early April 2026) + +The simplest approach reveals the core problem fastest. I started here because I thought the AI could handle branch management. It can't — at least not reliably. + +I started simple. One Squad, one repo, work on everything from the same checkout. + +It collapsed almost immediately. + +The core problem was context bleed. An agent working on DocumentDB content accidentally referenced Azure SQL patterns. Agents committed directly to main instead of branches — I literally put "all changes always go through a PR regardless of the repo" in all-caps in my instructions. Branch switching turned chaotic. An agent landed on the wrong branch, and a PR picked up commits from completely unrelated work. + +I found myself constantly redirecting: "No, that's the wrong repo." "No, switch branches first." "No, don't commit there." I spent more time babysitting than I would have spent doing the work myself. + +In one session I finally said it out loud: *"I'm having to be too interactive and redirecting across all projects and repos — how do I improve how I work so that you need less direction?"* + +The answer wasn't a better prompt. It was a better architecture. + +## Approach 2: Give each project its own squad (Mid-April 2026) + +When a shared workspace fails, the instinct is to isolate everything. That instinct is half right — isolation solves context bleed but creates a new problem that's equally painful. + +If one squad couldn't handle multiple projects, maybe each project needed its own squad. + +I spun up child squads: `mcp-doc-generation`, `ai-dev-tools-squad`, `content-maintenance`, `typespec-agent-squad`. Each had its own sub-coordinator, its own agents, its own config. + +Context isolation was perfect. Context *duplication* was a nightmare. + +Every squad needed its own `decisions.md`. Skills that worked everywhere — YAML validation, PR workflow rules, Acrolinx compliance checks — had to be manually copied to every squad. When I updated a skill in one place, the others went stale. I found myself sending messages like *"can you copy the m365 mcp from your mcp.json to all subsquads?"* — which tells you everything about the overhead. + +The deeper question was coordination. I asked my agents: *"How will the project PMs work with the individual repos they're responsible for — create PRs on those individual repos and spin up separate loops, or what? How do we make sure nothing is dropped, everything is logged, and the goal is reached instead of a different goal?"* + +Nobody had a clean answer. Because there isn't one — not when you've fragmented your team's brain across five repositories. + +The per-project model scales linearly in the wrong direction. Every new project means another squad to configure, another set of skills to maintain, another `decisions.md` that might contradict the others. At 8 projects, it's untenable. + +## Approach 3: Combine a central hub with git worktrees (Late April / May 2026) + +Here's what I discovered: the solution takes the shared brain from Approach 1 and the isolation from Approach 2, but shifts *where* the isolation happens. Instead of isolating entire squads, I isolate workspaces. + + + +![Architecture diagram showing hub as central brain with worktrees branching to isolated workspaces and repos.json routing to downstream repos](media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.png) + +One central Squad in `project-dina`— the same single brain from Approach 1 — but with a critical difference: I create git worktrees *before* entering Copilot CLI. + +Here's my actual worktree layout right now: + +``` +C:/Users/diberry/project-dina [squad/enable-worktrees] ← main checkout +C:/Users/diberry/data-plus-ai/docdb-article-2-3 [data-plus-ai/docdb-article-2-3] ← worktree +C:/Users/diberry/project-dina-azure-mcp-10 [content-gen-10] ← worktree +C:/Users/diberry/project-dina-blog-requirements [dfberry-blog/requirements] ← worktree +C:/Users/diberry/project-dina-content-gen-cli [decision/mcp-namespace-definition] ← worktree +``` + +That `git worktree list` output shows five active workstreams running simultaneously. Each worktree is a separate directory on disk, locked to a single branch, with the full hub config (agents, skills, decisions) available. + +A clarification that tripped me up at first: these are worktrees of the *hub repo* — not copies of every downstream product or content repo. The worktree gives each session its own branch, its own instructions, its own decisions and routing context. The actual product and content repos stay mapped through `repos.json` and cloned under `./repos/`. The worktree isolates the *orchestration layer*, not the target repos themselves. + +When I start a Copilot CLI session in a worktree, the LLM is already "in" the right branch. No switching to manage. The default path leads to the right place. + +This is the key insight: **the LLM doesn't need to manage branches if you give it a workspace that's already on the right branch.** + +Most of the problems from Approach 1 become much harder to hit — context bleed, branch confusion, accidental commits to main all require the agent to actively work against the worktree's defaults. And the problems from Approach 2 disappear entirely — skills are shared automatically from the hub, decisions live in one file, and there's exactly one squad to maintain. + + + +![Side-by-side comparison of babysitting loop with constant human redirects versus clean worktree flow ending in PR review](media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.png) + +The daily workflow change was immediate.Before: "No, wrong repo. No, switch branches first. No, don't commit there." After: create worktree, `cd` into it, start Copilot CLI, assign agent, review PR. Four steps, no redirecting. + +## Face the real effort: managing the framework itself + +The worktree trick solved the workspace problem. But I want to be radically honest about what it *didn't* solve — because if you stop at "just use worktrees," you'll hit the next wall within a week. The real work shifts from fighting the AI to maintaining the system around it. + +### Staff your agent roster like a team + +Without regular roster hygiene, you end up with ghost agents consuming context and muddying routing. This is people-management work wearing a technical mask. + +At 40+ agents, I manage a team roster. Agents get added for new domains, stale ones linger after projects wrap up, and over time I notice two agents doing roughly the same thing. I did a major consolidation pass — merging redundant agents, collapsing overlapping domains, renaming everyone to include their role and domain in the name (`Avery` → `Avery-pm-content-gen`). That rename cascaded into updating GitHub labels, routing tables, and casting registries. This is not a "set it and forget it" system. It's staffing. + +### Curate skills through a confidence lifecycle + +The difference between "worked once" and "reliably correct" is the difference between a tip and a skill. Without a confidence lifecycle, your skill library becomes a junk drawer of one-off patterns. + + + +![State diagram showing skill confidence transitions from low to medium to high with feedback loops](media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.png) + +Skills pile up naturallyas agents learn patterns, but I started encoding the project name in the skill folder to separate project-specific patterns from generic ones. Even then, there's a confidence lifecycle — a skill starts at low confidence, gets validated through repeated use, and eventually earns high confidence. Advancing a skill through that lifecycle takes human judgment. Nobody else is going to do it. + +### Keep the routing table honest + +When your routing table goes stale, agents guess instead of looking things up. One stale entry can send a PR to the wrong repo — and you won't catch it until review. + +`repos.json` maps 20+ repos to projects and PM agents. When I consolidated an internal repo into a different project, the routing table needed updating, the PM agent scope needed adjusting, and orphaned issues needed re-labeling. This is project management work — the framework just makes it explicit instead of implicit. + +### Prune decisions before they become wallpaper + +A decisions file that agents skim past is worse than no decisions file — it creates false confidence that conventions are being followed. + +`decisions.md` is the greatest strength and the biggest maintenance burden. Over time it grows into a massive file that agents skim past rather than internalize. I archive entries older than 30 days, deduplicate, and periodically do a junk-drawer cleanup to keep it actionable. Without curation, decisions accumulate but stop influencing behavior. This is a recurring cost, not a one-time fix. + +### Close the gap between "I have agents" and "agents do work" + + + +![Left-to-right pipeline showing human trigger through automated triage routing and execution to PR review and merge](media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.png) + +The ultimate goal is one command→ auto-triage → route to the right agent → execute → open PR → review → merge. Getting there requires meaningful issue labels, triage rules in routing, auto-assignment patterns, and agents that genuinely know their scope without being told. Each iteration gets closer. But the gap between "I have agents" and "agents do work without me" is filled with exactly this kind of infrastructure. The "Ralph, go" aspiration is still aspirational. + +### Accept that cross-project awareness is unsolved + +Even the best architecture can't give you a mental model of everything in flight. This is the frontier — and it's honest to say nobody has cracked it yet. + +Even with the hub model, knowing what's happening across all 8 projects simultaneously is hard. I use daily briefs, orchestration logs, and session history, but the mental model of "what's in flight right now" still lives partly in my head. No framework I've seen has fully cracked multi-project awareness yet. + +The honest summary: the hub + worktrees architecture moved the hard work from "fighting the AI about branches and context" to "maintaining the system that makes the AI productive." That's a better class of problem. Boring and that's good. But it's still a problem, and it's ongoing. + +## Compare the trade-offs + +Every approach solves some problems and creates others. This table captures my experience — not theoretical scores, but what I actually hit across two months of iteration. + + + +| Dimension | Same directory | Squad per project | Hub + worktrees | +|-----------|---------------|-------------------|-----------------| +| Context isolation | ❌ Bleed everywhere | ✅ Perfect | ✅ Branch-level | +| Shared skills | ✅ Automatic | ❌ Must copy everywhere | ✅ Automatic from hub | +| Shared decisions | ✅ One file | ❌ Fragmented | ✅ One file | +| Agent confusion | ❌ Wrong branches | ✅ Clean | ✅ Clean | +| Setup overhead | ✅ Minimal | ❌ Heavy (N squads) | 🟡 Moderate | +| Cross-project coordination | ❌ Manual redirecting | ❌ No shared brain | ✅ Hub coordinates | +| Workspace discipline | ❌ Must manage branch state | ✅ No switching needed | ✅ No switching needed | +| Scaling | ❌ Collapses at 5+ projects | 🟡 Linear overhead | ✅ Scales well | +| PR workflow | ❌ Commits to main | ✅ Clean | ✅ Each worktree = one PR | + +The hub + worktrees model has real costs beyond that 10-second setup command. Worktrees accumulate — you need a cleanup habit or your disk fills up with stale branches. Branch names need to be meaningful because they *are* your task identifiers; `fix-stuff-3` helps no one. And `decisions.md` requires curation — without occasional pruning, it becomes a junk drawer that agents skim past instead of reading. These are maintenance costs, not architectural ones, but they're real. + +## Six things I learned the hard way + +These lessons didn't come from documentation — they came from wasted sessions and frustrated redirecting. Each one represents a problem I had to hit before I understood the fix. + +**1. Domain-encode your agent names.** When I had 40 agents named things like "Avery" and "Morgan," I couldn't remember who did what. Renaming them to `Avery-pm-content-gen` and `Morgan-eng-typespec` made the entire system legible at a glance. The naming convention is `{name}-{role}-{domain}`. It sounds bureaucratic. It saves real time. + +**2. Create a routing table, not a mental model.** `repos.json` maps every repo to its project, its owning PM agent, its auth type, and its sweep config. When an agent needs to know which project owns a repo, it looks it up instead of guessing. When *I* need to know, I look it up instead of remembering. Externalize the routing. + +**3. Let skills accumulate, not duplicate.** In the hub model, when any agent learns a new skill — YAML validation, Rust SDK patterns, Acrolinx compliance — it's immediately available to every project. In the per-project model, skills are siloed. Over two months, the hub accumulated 15+ shared skills that would otherwise be fragmented across 8 separate squads. + +**4. One `decisions.md` changes everything.** When you have one canonical decisions file, agents don't make the same mistake twice. "We use relative URLs, never absolute, in Microsoft Learn content." "All PRs must target the `-pr` (internal) repo, never the public mirror." Decisions propagate automatically because every session reads the same file. + +**5. The "too interactive" problem is a design smell.** If you're constantly redirecting agents, the architecture is wrong. The goal is to say "Ralph, go" and have work happen. That requires auto-triage, domain-aware routing, and agents that know their scope without being told every time. If you're babysitting, fix the structure — not the prompts. + +**6. Make workspace setup a gate.** Don't ask the LLM to choose a branch or switch context. Give it a directory where the correct branch and instructions are already true. If the workspace is wrong, no amount of prompting fixes it reliably. If the workspace is right, you barely need prompts at all. This is arguably the central takeaway from two months of iteration. + +## Where to start + +If you're managing more than a couple of projects with AI agents, here's what I'd try: + +1. **Start with one hub repo.** Put your squad config, skills, and decisions here. This is your single brain. +2. **Put repos.json at the root.** Map every repo you work on to a project. Include the PM agent who owns it. +3. **Use worktrees for isolation.** Before starting a Copilot CLI session, run `git worktree add ../my-task-dir my-branch`. Work in the worktree directory. The LLM inherits the right branch automatically. +4. **Name agents with their domain.** `{name}-{role}-{domain}`. You'll thank yourself at agent 15. +5. **Log decisions centrally.** Every decision, every convention, every "don't do this" — one file, read by every session. +6. **Make workspace setup the gate.** If the directory is wrong, the session is wrong. Get this right first. + +The surprising thing isn't that AI agents need structure. It's that the structure that works best is one of the oldest tools in git's toolbox — worktrees — combined with one of the oldest patterns in systems design: a centralized brain with distributed execution. + +The LLM doesn't need a smarter prompt. It needs a workspace where the right thing is the default. + +How do you handle multi-project AI coordination? I'm genuinely curious — let me know what patterns you've found. diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.mmd new file mode 100644 index 0000000..905d40a --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.mmd @@ -0,0 +1,36 @@ +flowchart LR + subgraph Before["🔴 Before: Babysitting Loop"] + direction TB + B1["Start session"] --> B2["Agent picks\nwrong branch"] + B2 --> B3["Human redirects"] + B3 --> B4["Agent picks\nwrong repo"] + B4 --> B5["Human redirects"] + B5 --> B6["Agent commits\nto main"] + B6 --> B7["Human redirects"] + B7 --> B1 + end + + subgraph After["🟢 After: Worktree Flow"] + direction TB + A1["Create worktree"] --> A2["cd into directory"] + A2 --> A3["Start Copilot CLI"] + A3 --> A4["Assign agent"] + A4 --> A5["Review PR"] + A5 --> A6["✅ Done"] + end + + style Before fill:#fff0f0 + style After fill:#f0fff0 + style B1 fill:#dc3545,color:#fff + style B2 fill:#dc3545,color:#fff + style B3 fill:#ff6b6b,color:#fff + style B4 fill:#dc3545,color:#fff + style B5 fill:#ff6b6b,color:#fff + style B6 fill:#dc3545,color:#fff + style B7 fill:#ff6b6b,color:#fff + style A1 fill:#28a745,color:#fff + style A2 fill:#28a745,color:#fff + style A3 fill:#28a745,color:#fff + style A4 fill:#28a745,color:#fff + style A5 fill:#28a745,color:#fff + style A6 fill:#1b5e20,color:#fff diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.png new file mode 100644 index 0000000..369903e Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.mmd new file mode 100644 index 0000000..73cd83a --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.mmd @@ -0,0 +1,25 @@ +flowchart TB + subgraph Hub["🧠 project-dina Hub"] + SA["squad.agent.md"] + DM["decisions.md"] + SK["skills/"] + end + + Hub -->|"shared config"| W1["📂 blog-requirements\nproject: dina"] + Hub -->|"shared config"| W2["📂 docdb-article\nproject: data-plus-ai"] + Hub -->|"shared config"| W3["📂 azure-mcp\nproject: azure-ai-tools"] + Hub -->|"shared config"| W4["📂 content-gen-cli\nproject: content"] + + RJ["repos.json\nRouting Table"] -->|"routing"| R1["internal-repo-1"] + RJ -->|"routing"| R2["internal-repo-2"] + RJ -->|"routing"| R3["internal-repo-3"] + RJ -->|"routing"| R4["personal-repo-1"] + + Hub --- RJ + + style Hub fill:#1a73e8,color:#fff + style W1 fill:#34a853,color:#fff + style W2 fill:#34a853,color:#fff + style W3 fill:#34a853,color:#fff + style W4 fill:#34a853,color:#fff + style RJ fill:#fbbc04,color:#000 diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.png new file mode 100644 index 0000000..f93b73c Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/image-references.md b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/image-references.md new file mode 100644 index 0000000..f7c8bfa --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/image-references.md @@ -0,0 +1,41 @@ +# Image References for "The Worktree Trick" Blog Post + +Use these markdown snippets to embed each diagram in the blog post. + +--- + +## 1. Three Approaches Progression +**Alt text:** Flowchart showing progression from same-directory approach through per-project squads to hub plus worktrees solution +```markdown +![Flowchart showing progression from same-directory approach through per-project squads to hub plus worktrees solution](media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.png) +``` + +## 2. Hub + Worktree Architecture +**Alt text:** Architecture diagram showing hub as central brain with worktrees branching to isolated workspaces and repos.json routing to downstream repos +```markdown +![Architecture diagram showing hub as central brain with worktrees branching to isolated workspaces and repos.json routing to downstream repos](media/2026-05-08-worktree-trick-multi-project-ai-teams/hub-worktree-architecture.png) +``` + +## 3. Before and After Workflow +**Alt text:** Side-by-side comparison of babysitting loop with constant human redirects versus clean worktree flow ending in PR review +```markdown +![Side-by-side comparison of babysitting loop with constant human redirects versus clean worktree flow ending in PR review](media/2026-05-08-worktree-trick-multi-project-ai-teams/before-after-workflow.png) +``` + +## 4. Skill Confidence Lifecycle +**Alt text:** State diagram showing skill confidence transitions from low to medium to high with feedback loops +```markdown +![State diagram showing skill confidence transitions from low to medium to high with feedback loops](media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.png) +``` + +## 5. Ralph Go Pipeline +**Alt text:** Left-to-right pipeline showing human trigger through automated triage routing and execution to PR review and merge +```markdown +![Left-to-right pipeline showing human trigger through automated triage routing and execution to PR review and merge](media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.png) +``` + +## 6. Tradeoff Comparison +**Alt text:** Grid comparing same directory versus per-project squads versus hub plus worktrees across six dimensions including context isolation and scaling +```markdown +![Grid comparing same directory versus per-project squads versus hub plus worktrees across six dimensions including context isolation and scaling](media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.png) +``` diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/pnw-river-delta-hub-worktrees.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/pnw-river-delta-hub-worktrees.png new file mode 100644 index 0000000..bf830d3 Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/pnw-river-delta-hub-worktrees.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.mmd new file mode 100644 index 0000000..a8aee1c --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.mmd @@ -0,0 +1,23 @@ +flowchart LR + H1["👤 Human\nsays 'go'"] --> T["Issue triage"] + T --> R["Agent routing"] + R --> E["Execution"] + E --> PR["PR created"] + PR --> H2["👤 Human\nreview"] + H2 --> M["Merge"] + + subgraph Auto["The gap to close"] + T + R + E + PR + end + + style H1 fill:#1a73e8,color:#fff + style H2 fill:#1a73e8,color:#fff + style M fill:#28a745,color:#fff + style Auto fill:none,stroke:#ff6b6b,stroke-width:2px,stroke-dasharray: 5 5 + style T fill:#ffc107,color:#000 + style R fill:#ffc107,color:#000 + style E fill:#ffc107,color:#000 + style PR fill:#ffc107,color:#000 diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.png new file mode 100644 index 0000000..1e46661 Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/ralph-go-pipeline.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.mmd new file mode 100644 index 0000000..8d78cd5 --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.mmd @@ -0,0 +1,12 @@ +stateDiagram-v2 + [*] --> Low: Pattern observed + Low --> Medium: Repeated successful use + Medium --> High: Human review + cross-project validation + High --> Medium: Context drift / edge case found + Medium --> Low: Repeated failures + + Low: 🟡 Low Confidence (new / untested) + Medium: 🟠 Medium Confidence (validated in 2-3 contexts) + High: 🟢 High Confidence (reliable across projects) + + note right of High: Nobody else is going to do it. diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.png new file mode 100644 index 0000000..a069a77 Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/skill-confidence-lifecycle.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.mmd new file mode 100644 index 0000000..87ab10b --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.mmd @@ -0,0 +1,15 @@ +flowchart TD + Start["Multi-project AI agents"] --> A1["Approach 1: Same directory"] + A1 --> F1["❌ Context bleed, branch chaos"] + F1 --> D1{"Try isolation?"} + D1 --> A2["Approach 2: Per-project squads"] + A2 --> F2["❌ Skill duplication, no shared brain"] + F2 --> D2{"Combine strengths?"} + D2 --> A3["Approach 3: Hub + worktrees"] + A3 --> S1["✅ Shared brain + isolated workspaces"] + + style F1 fill:#dc3545,color:#fff + style F2 fill:#dc3545,color:#fff + style S1 fill:#28a745,color:#fff + style D1 fill:#ffc107,color:#000 + style D2 fill:#ffc107,color:#000 diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.png new file mode 100644 index 0000000..2a6e88e Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/three-approaches-progression.png differ diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.mmd b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.mmd new file mode 100644 index 0000000..17eaab5 --- /dev/null +++ b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.mmd @@ -0,0 +1,31 @@ +block-beta + columns 4 + space:1 C1["Same Directory"]:1 C2["Per-Project Squads"]:1 C3["Hub + Worktrees"]:1 + R1["Context isolation"]:1 V1["❌ Bleed"]:1 V2["✅ Perfect"]:1 V3["✅ Branch-level"]:1 + R2["Shared skills"]:1 V4["✅ Auto"]:1 V5["❌ Copy everywhere"]:1 V6["✅ From hub"]:1 + R3["Shared decisions"]:1 V7["✅ One file"]:1 V8["❌ Fragmented"]:1 V9["✅ One file"]:1 + R4["Agent confusion"]:1 V10["❌ Wrong branches"]:1 V11["✅ Clean"]:1 V12["✅ Clean"]:1 + R5["Setup overhead"]:1 V13["✅ Minimal"]:1 V14["❌ Heavy"]:1 V15["🟡 Moderate"]:1 + R6["Scaling"]:1 V16["❌ Collapses"]:1 V17["🟡 Linear"]:1 V18["✅ Scales well"]:1 + + style C1 fill:#6c757d,color:#fff + style C2 fill:#6c757d,color:#fff + style C3 fill:#1a73e8,color:#fff + style V1 fill:#dc3545,color:#fff + style V5 fill:#dc3545,color:#fff + style V8 fill:#dc3545,color:#fff + style V10 fill:#dc3545,color:#fff + style V14 fill:#dc3545,color:#fff + style V16 fill:#dc3545,color:#fff + style V2 fill:#28a745,color:#fff + style V3 fill:#28a745,color:#fff + style V4 fill:#28a745,color:#fff + style V6 fill:#28a745,color:#fff + style V7 fill:#28a745,color:#fff + style V9 fill:#28a745,color:#fff + style V11 fill:#28a745,color:#fff + style V12 fill:#28a745,color:#fff + style V13 fill:#28a745,color:#fff + style V18 fill:#28a745,color:#fff + style V15 fill:#ffc107,color:#000 + style V17 fill:#ffc107,color:#000 diff --git a/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.png b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.png new file mode 100644 index 0000000..3583c3d Binary files /dev/null and b/website/blog/media/2026-05-08-worktree-trick-multi-project-ai-teams/tradeoff-comparison.png differ