Herdr: första agentverktyget som klickade
Jag har provat en del verktyg för att hantera flera kodagenter samtidigt. cmux, Conductor, emdash, Superset. Inget av dem fastnade, och det tog ett tag innan jag kunde sätta fingret på varför.
Det var två saker som återkom. Antingen låg verktyget för långt från terminalen, som Conductor med en helt egen app och cmux med en egen terminal, och jag tänker inte överge Ghostty bara för att jobba med agenter. Eller så snurrade det upp ett git worktree per session som default. Det första är väl en smaksak. Det andra tycker jag är mer principiellt fel. Ibland vill jag bara spåna. Ställa en fråga om en fil, läsa lite kod, testa en idé som dör efter två minuter. Att det ska kosta ett worktree, en branch och en npm install varje gång är helt fel växel att ligga i.
Herdr låg tillräckligt nära
Min gamla setup var flera Ghostty-tabbar med panes i: en agent här, lazygit där, en dev-server längst ner. Lite ostrukturerat, men det funkade ändå hyfsat bra.
Herdr kändes direkt som samma sak. Workspaces, tabbar, panes, allt kvar i terminalen. Skillnaden är att Herdr vet vad en agent är. Den ser vilka panes som kör Claude och i vilket läge de befinner sig (idle, working, blocked, done), och exponerar alltihop via ett herdr-CLI. Vilket i sin tur betyder att Claude själv kan hantera tabbar och panes, läsa vad som händer i en annan pane och snurra igång nya sessioner.
Att det är ett TUI med bra musstöd sänkte tröskeln rejält. Jag kunde klicka mig fram från dag ett och lära mig kortkommandon efter hand, samma sak som jag gillar med Hunk. Och att man kan stänga ner allt och komma tillbaka till exakt samma workspace, med panes och agenter kvar där de stod, är rätt smidigt.
Herdr gör inte heller särskilt många antaganden om hur man förväntas jobba. Man får en sidebar med sina spaces och en agentvy, sen är det upp till en själv att avgöra hur de ska användas: ett eller flera spaces för samma repo, vad som ska vara en egen tabb och vad som ska vara en pane. Jag har landat i ett space per repo, där varje repo har en Home-tabb som jag gör det huvudsakliga arbetet i, vanligtvis med lazygit i en split pane bredvid. Parallella spår sker oftast i egna tabbar, men inte alltid.
Men worktrees, då
Där fastnade det ändå. För även om jag inte vill ha worktrees per default så vill jag definitivt ha dem när arbetet faktiskt är parallellt. Herdr har en egen herdr worktree open, men den öppnar worktrees som egna workspaces, och det var inte modellen jag var ute efter.
Det som gjorde det svårt var jobbet. Ett av repona där är ett stort monorepo, och ett nytt worktree är inte git worktree add och klart: env-filer ska kopieras och node_modules fyllas för just de targets man ska jobba i. Jag hade redan en egen Claude-skill som gjorde det, och den fungerade bra. Det räckte alltså inte att det gick att jobba i mina egna repon med Herdr, det behövde hantera jobbrepona lika friktionsfritt.
Herdr har pluginstöd. Så jag lät Claude bygga ett.
herdr-treehouse
Mentala modellen är att ett workspace är ett repo och en tabb är ett worktree. Alla worktrees för samma repo ligger som tabbar bredvid varandra, och överblicken sitter precis där. Pluginet ligger på GitHub.
treehouse up skapar worktreet, kör uppsättningen, öppnar tabben, sätter pane-layouten och startar en agent. treehouse down river det. treehouse onboard skannar ett nytt repo och föreslår en config.
En liten detalj som visade sig göra mer nytta än jag trodde: pluginet prefixar alla worktree-tabbar med ett 🌳, så etiketten blir 🌳 abc-1234. Jag ser direkt i tabblistan vilka tabbar som är worktrees, och i agentöversikten vilka agenter som jobbar i ett worktree och vilka som står i huvudcheckouten.
Allt styrs av en toml-config som säger åt pluginet hur ett visst repo ska sätta upp ett worktree. Var worktreet ska ligga (jag gillar att ha dem som sibling-mappar bredvid huvudcheckouten), vad som behöver köras för att det ska gå att jobba i (kopiera .env-filer, installera dependencies), och vilka panes tabben ska ha. Det finns också stöd för att injecta en repo-specifik prompt till agenten som startar i worktree-tabben, alltså sånt agenten omöjligt kan veta själv: att den står i ett worktree och inte i huvudcheckouten, var node_modules faktiskt finns.
Ett repo-block kan se ut så här:
[repos.some-repo]root = "path/to/repo"base = "origin/master"setup = ["npm install"]
[[repos.some-repo.panes]]split = "down"label = "dev"command = "npm run dev"Uppsättningen har två nivåer. setup är en lista shell-kommandon som körs i ett färskt worktree, och den räcker gott för de flesta repon. bootstrap är för när det inte gör det. I stället för kommandon pekar man ut ett skript, typiskt ett bash-skript, som tar över hela worktree-skapandet. Skriptet får branchnamn, sökväg och targets som argument och ansvarar själv för allt från git worktree add till att installera rätt saker. Det är den här vägen monorepot i jobbet går.
down river worktreet igen, men vägrar vid ocommittade ändringar och vid panes som kör processer.
En sak jag medvetet byggde in är att repo-configen kan ligga utanför själva repot. Antingen som ett [repos.X]-block i en central fil under ~/.config/herdr/, eller som en .treehouse.toml i repot självt. Jag vill inte checka in plugin-config i jobbrepona, det här är ju något bara jag kör med i teamet. Mina egna projekt får ha filen i repot, jobbrepona ligger centralt.
När pluginet var på plats lämnade jag min gamla vanilla-setup. Nu kör jag Herdr inuti Ghostty, vilket är ungefär den kompromiss jag ville ha från början. Verktyget lägger sig ovanpå det jag redan trivdes med istället för att ersätta det.
Skillsen ovanpå
Runt det här har det blivit en handfull skills. De är de som gör att flödet triggas i fritext istället för att jag ska minnas kommandon.
herdr-worktree och herdr-worktree-teardown tolkar kontexten jag ger dem, ett Jira-ärende, en GitHub-issue eller bara en beskriven uppgift, och anropar sen pluginet för att sätta upp eller riva worktreet.
herdr-repo-onboard kör jag en gång per repo. Den skannar kodbasen, gissar hur ett worktree bör sättas upp och skriver ett förslag på plugin-konfiguration för det repot.
herdr-second-opinion splittar en pane och startar en read-only Claude-session i samma working tree. Hela poängen är att agenten som skrivit koden inte ska vara den som granskar den. En färsk session i samma träd, utan min konversation i bagaget, hittar andra saker. Read-only bärs både av en deny-regel och av briefen, så den inte ens försöker.
herdr-handoff är den jag underskattade mest innan jag byggde den. När ett sidospår dyker upp mitt i något annat, en bugg jag råkar snubbla på eller en idé som förtjänar en egen branch, bygger den en självbärande brief ur den pågående konversationen och startar en ny agent i en egen pane. Den tar sidospåret hela vägen medan jag fortsätter med huvudspåret.
herdr-hunk-review är för när jag vill granska själv. Den öppnar Hunk i en split pane bredvid agentens pane, så diffen och chatten ligger sida vid sida. Jag kommenterar inline där jag faktiskt läser koden, och när jag är klar räcker det att jag skriver “apply” i chatten: då läser agenten kommentarerna ur den levande sessionen och åtgärdar dem. Granskning och åtgärd är alltså två steg i samma skill.
Från ticket till PR
Så här ser ett ganska vanligt arbetsflöde ut nu. Jag pekar huvudagenten i Home-tabben på en ticket, eller på flera om de saknar blockers och beroenden sinsemellan, och ber den snurra igång ett worktree per ticket i Herdr och delegera uppgifterna dit. Sen jobbar de parallellt i var sin tabb. Huvudagenten instruerar agenten i worktree-tabben att göra jobbet och skapa en PR, och när den är klar delegerar den i sin tur code review vidare till ytterligare en agent via second opinion-skillen, med fräsch kontext i samma träd. Själv kliver jag in när det finns en PR att titta på. Är det något jag känner att jag vill granska ordentligt kör jag hunk review-skillen och gör min egen review, men det sker främst i jobbrepona. Privat är det mer vilda västern.
Det är också det flödet som syns i siffrorna. Min token usage gick från ungefär 100M i veckan före det här till runt 600M efter. Det är inte overhead från Herdr, det är att jag gick från en session i taget till 15–26 om dagen. Fast veckan var speciell. Jag byggde både skillsen och treehouse-pluginet samtidigt, och delegerade rätt små uppgifter till egna worktrees mest för att se om arbetssättet håller. Det gjorde det. Jag tror inte sexdubblingen håller i sig varje vecka, men usage limit är onekligen något att hålla koll på, och blir det ett problem är det den här kedjan av delegeringar som behöver förfinas först.
Mina skills för vanilla-setupen med Ghostty finns kvar, jag har inte tagit bort dem ännu. Men än så länge ser jag ingen anledning att gå tillbaka. Herdr är det första AI-verktyget jag inte slängt bort efter att ha testat det en liten stund.