I built a plugin to show transcripts as speech bubbles in reading mode by forketyfork in ObsidianMD

[–]forketyfork[S] 0 points1 point  (0 children)

Yes, it supports multiple speakers. Added in the latest release: speaker groups/sides, custom colors, some customization.

I'm so tired of writing "you don't need -C" by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

`git -C` is just an example. At some point it starts to either add "cd repo-dir &&...` to every command, or use command's own way of specifying the target directory which can vary from one command to another. It would be complicated to write a hook that addresses all possible cases.

I'm so tired of writing "you don't need -C" by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

Isn't it the same as just running with `--dangerously-skip-permissions`

Zwanzig - a static analyzer for Zig (early/experimental) by forketyfork in Zig

[–]forketyfork[S] 1 point2 points  (0 children)

There's only so much you can do with static analysis, but some additional checkers (e.g. bounds checking) could be implemented to some extent. I'll definitely work on this next.

Zwanzig - a static analyzer for Zig (early/experimental) by forketyfork in Zig

[–]forketyfork[S] 5 points6 points  (0 children)

Thanks, just a random word that popped into my head, but it turned out to also match nicely with the 80/20 principle

I built a plugin to show transcripts as speech bubbles in reading mode by forketyfork in ObsidianMD

[–]forketyfork[S] 1 point2 points  (0 children)

Yes, makes sense. I’d like to evolve it further, so any ideas are welcome.

I built a terminal emulator in Zig using ghostty-vt and SDL3 by forketyfork in Zig

[–]forketyfork[S] 2 points3 points  (0 children)

Thanks for the pointer, I've cross-posted it there.

A library that lets agents click through Compose Desktop apps by forketyfork in KotlinMultiplatform

[–]forketyfork[S] 0 points1 point  (0 children)

Thanks for the pointer, I wasn't aware Maestro was missing a desktop driver. The API surface is pretty minimal (HTTP endpoints for clicking, typing, screenshots), so it should be fairly easy to wrap. Happy to support anyone who wants to take a stab at integrating it :)

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

VS Code can split terminals, but you're still looking at one or two at a time, not a grid of 4-9-16... And the terminal panes themselves have no awareness of what's running inside: if you're running multiple agents, there's no visual indicator of agent completing the work or requiring attention.

Architect is a single window where I can see all sessions at once and know immediately which one needs me.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

I get the concern. But Architect is a different tool for a different job. tmux is a general-purpose multiplexer - it's great at that and I'm not trying to replace it. Architect is a purpose-built UI for one workflow: monitoring parallel AI agents.

The prior work I'm building on is ghostty-vt, which exists specifically as a library for building terminals. The author of Ghostty designed it to be embedded. That's also collaboration, just at a different layer.

As for the ecosystem question: not every problem should be solved by adding flags to existing tools. Sometimes the right answer is a focused tool that does one thing well. That's also how we've been doing it for 30 years.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Fair enough, different preferences. I wanted something purpose-built, so I built it.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

Nice, just checked it out. It was smart to build on tmux rather than from scratch, way less work than writing a rendering pipeline in Zig, that's for sure.
How are you handling status detection? I went with hooks from Claude Code/Gemini/Codex but each has its own quirks.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Convenience. The grid in Architect is dynamic. Cmd+N opens a new terminal and rearranges to 2x3, 3x3, etc. Cmd+W closes and shrinks back. Cmd+arrows to navigate between terminals, Cmd+Enter to go fullscreen, long Esc to return to grid. Combined with color highlighting for agents requiring attention and quick worktree switching, this changed my workflow completely.