wild_egg

I've actually built up a set of Claude Skills for creating and using tickets. Currently overhauling them based on what I've found to be most effective. Will probably publish those in a week or two when I've nailed down what I want there.

I haven't seen any great content around this though. I've gone through a lot of trial and error with different approaches over the last few months.

Biggest thing I can say: plan up front. I frontload basically all of my involvement and have Claude do a ton of research to make a very detailed plan document and then the plan gets decomposed into a graph of tickets. I have some other tooling that orchestrates delegating the tickets to focused Claude Code sessions and they can work through them mostly autonomously for many hours until the work is done.

Great call out. The agents will set those on `create` calls but don't typically reference them afterwards.

I have a fairly robust orchestration layer built on top of this tool that relies heavily on those fields though. But without that, they are a bit noisy.

Mixed feelings on upward search. One of my pain points with beads was that agents would sometimes create a bead outside of the correct directory and get dumped into a global `~/.beads/default.db` and make a mess. They've done that a couple times with ticket but run `tk ready` afterwards, see the new ticket is the only one, realize their mistake, and then relocate the ticket into the correct location. Still thinking on that one.

It really would. That's on my TODO list for next weekend.

I may actually make a slimmer one for that use case though. There are a number of commands here that are really only useful at the orchestration layer and would be mostly noise in a pure Skill context.

Ah I don't delete these or really look at the `.tickets/` directory. I have about 1900 tickets in one project and navigate them through VS Code. Ctrl+t does fuzzy finding across all markdown headers and I Crtl+Click in the terminal quite a lot to jump to ticket files.

But yes, dependencies are everything here. I use `tk dep tree` regularly to visualize the graph and click on the things I want details on. Typically I don't have too crazy of a list of open tickets so it's easy enough to find things by running `tk ready` and `tk blocked` and clicking what I'm looking for. For historical things, I just search in the `git log` pager.

If it'd be useful though, I can look at a `tk delete` command that deletes a given ticket and all of its dependencies to clean up a whole tree in one shot. Not sure I'd ever use it myself though.

Thanks! I agree completely. Dependency tracking is such a vital part of organizing work and it's hard to find good tooling for that. Beads started out as one and I wanted to maintain the simplicity it used to offer.

And I may just go make a README tweak re: unix philosophy... The MVP story floated up from the back of my mind when I went to go build this but you're totally right.

I'm not familiar with enough to say concretely. What's the dependency management experience like with those? That's really the core of my needs.

On the surface though, those are both significantly heavier tools. At minimum, there's a learning or adaption curve. I had built workflows on top of Beads and making a drop-in replacement was easier than reworking all of them.

Is there a way to do dependency tracking with `git notes`? That's really the core thing for me. I like to do a ton of up-front planning work, split it all out into a graph of tickets and then let agents chew threw them until done.

There aren't a whole lot of tools that have a clean interface for that workflow though.

It's a great question. I'm sure the answer varies a lot by who you ask.

For me, there's a ton of extra control and capability from having things local. Nothing wrong with github, and agents are great with the gh CLI, but it's really not quite the same.

Plus, having it based on directory structure rather than repo means I can locate tickets where the work actually happens. Not everything I work on is on github, and some of the things that are on github are in monorepos where each project really deserves its own set of tickets.

I still find it so fascinating how experiences with these models are so varied.

I find codex & 5.2 Pro next to useless and nothing holds a candle to Opus 4.5 in terms of utility or quality.

There's probably something in how varied human brains and thought processes are. You and I likely think through problems in some fundamentally different way that leads to us favouring different models that more closely align with ourselves.

No one seems to ever talk about that though and instead we get these black and white statements about how our personally preferred model is the only obvious choice and company XYZ is clearly superior to all the competition.

What sort of tooling is missing in Lisp? I'd love to check out your framework if you've shared it somewhere

Your employer is not paying for these things?

> Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code.

You're overthinking htmx then. I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.

Server always has authoritative state and code is dead simple to reason about.

What does Tmux-CLI add on top of regular tmux?

Everything in the "What Claude Code Can Do With Tmux-CLI" section is already easily possible out of the box with vanilla tmux

The baseline configurations all note <2s and <3s times. I haven't tried any voice AI stuff yet but a 3s latency waiting on a reply seems rage inducing if you're actually trying to accomplish something.

Is that really where SOTA is right now?

It takes a dozen tokens to put "when you need to do X, run `foo --help` and use it" in your CLAUDE.md.

Plenty of MCPs and plugins and whatnot out there idly consuming 5-25k tokens 24/7. How is that the same?

CLIs don't use context space when unused. I find them almost universally preferable just because of that.

Models get stupid after the first 80-100k tokens are used so keeping bloated tools out of the window unless completely necessary is a pretty hard requirement for effective AI use IMO.

Sounds both preposterous and promising. Anyone here speak Polish and can weigh in?

I've now done this multiple times with older Claude versions.

If the project is complex, a key thing is telling it to do a 1:1 migration with full equivalent test coverage, following TDD best practices. That gives it the right structure to reliably test its own work and the results are consistently solid.

Typo in the title? Article is about Slack.

Sorry to say but 2013 was more than a few years ago...

This. I have a massive amount of custom software running locally to solve all sorts of problems for me now.

But it's for me and tailor made to solve my precise use cases. Publishing it would just add headaches and endless feature requests and bug reports for zero benefit to me.

None of the macro systems in those languages are really equivalent to lisp macros.

If you really want static typing, Lisp macros are powerful enough to implement a full ML type system in userspace as a library.

See https://coalton-lang.github.io

> Everything you said could apply to a new bridge, building, pharmaceutical compound

"Everything"? So

> predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0.

Also applies to bridges? Bridges require a ton of manual human input at every stage of construction, regardless of how predictable and repetitive the work is. With software, we can write software to make those tasks disappear. I've yet to see the bridge that can build itself.

I missed that part of the manifesto

This feels like something I want but it's hard to be sure. An example use case in the Introduction would be helpful

More efficiency just means more consumption. Think when they add lanes to a highway, traffic gets better for a little bit but very soon the highway is just as congested as before.

Modern UX trends are a scourge of excessive whitespace and low information density that get in the way of actually accomplishing tasks.

Any project that rejects those trends gets bonus points in my book.

I might just not be following correctly but committing in git just carries the branch along for the ride, so there's nothing to do in git for this scenario.

IIRC forcing some specific branch name to point to my changes with `jj` was non-obvious and what made me give up and go back to git when I tried it last year.

Basically experts at it, works great.

XFCE is plenty mature and very stable