PriorityQueue.dev
Cross-repo project view to help manage the chaos of orchestrating multiple agents across unrelated workstreams. Spiritual successor to Pivotal Tracker.
Priority Queue is a project management app that exists somewhere between “we have linear at home” and Pivotal Tracker. It provides a naively simple and flat view of your project, but it’s unique in that it takes advantage of a lot of free or very cheap infra. The goal is two fold:
- Provide a unified view of all the different workstreams I have going on
- Be able to scope out larger chunks of work that I can hand off a longer range task to a ralph wiggum loop in claude code.
Check it out: PriorityQueue.dev
How I use it
It’s a control plane over GitHub Issues. Given that the gh cli is easily accessible to many tools, I treat each repo’s Github issue backlog as a mailbox to send work. PriorityQueue steps in to bring order across repos. It’s VERY equivalent to Github’s project or milestone view, and as a matter of fact it uses some of those tools underneath. What it adds is more of the usability from Linear or Pivotal Track. Namely: an absolutely ordered priority stack, ease of rearranging, and a place to deposit project and discovery notes.
Where it shines is how it integrates into my claude loop.
At the end of each claude session, I have a skill called follow-up-tasks which reviews the session and the completed code and identifies incomplete work. Claude’s findings become new tickets in the backlog.
I have another skill called /groom-backlog which reviews all the tickets, researches the current state, and matches it up with the larger “VISION.md” or “PRD.md” files I’m running off of. It then uses a known sorting algorithm to order items nad group them into workstreams.
Finally, in claude, I can simply prompt with /dev Foo Workstream. This dev skill will pull the workstream from PriorityQueue – including project notes and all tickets – then route the dev sequence to either a ralph loop, rpi, or simple fix with complete context.
How it’s built
The frontend is mostly React + Tailwind + Vite on top of vercel. The backend is currently on a “personal” supabase instance which has arbitrary tables. It’s close to reaching the point of needing its own backend instance instead of sharing.
Future vision
I’m planning on integrating Ponko into this. I want to be able to kick off an agent to do project management skills straight from the UI. I also want to be able to attach a compute runner that can work on tickets without me monitoring it.
I also have two related processes I’d like to merge in.
The first is an architectural steering system, which is a way to view repos from the perspective of each repo’s current architectural design and issue new ADRs to steer the architecture back. This would primarily be for “lights out” code bases that are almost entirely written with coding agents.
The second is a design consultancy system. It’s a way to view repos from the perspective of its visual design. I’m currently building up a design knowledge base as well as a formal process for intaking workstreams and generating mockups to attach straight to issues.
I currently run both the architectural steering and design consultancy systems as AI enabled project folders. I’d like to formalize them as I battle test them locally more.