The Problem
I had 50 open issues and no idea which one to start. Priority labels said one thing. My gut said another. Three days into a P1, I discovered it was blocked by a P2 I’d been ignoring. That P2 was blocking four other things downstream. My issue tracker couldn’t see any of that. It showed me a list. The dependencies lived in my head, invisible to my tools, invisible to anyone else on the project. So I modeled the backlog as a graph and ran PageRank on it. That’s how ticket-rs started. The timing turned out to be right. The industry is converging on what Martin Fowler calls context engineering: curating what the model sees so you get better results. Anthropic, Spotify, OpenAI — they’re all publishing about the same problem. Coding agents need structured context. Your backlog’s dependency graph is exactly that context.Vibe Coding and Its Discontents
Coding agents are getting good. Good enough that people ship features without reading the code. Vibe coding: trust the model, force push, say a prayer. It works for prototypes. It doesn’t work when you have real dependencies and real users. The problem isn’t the agents. They’re useful when you give them structure. The problem is that most workflows don’t provide any.Structure, Not Whimsy
Steve Yegge’s beads was one of the first projects to ask the right question: what if issue tracking was terminal-native instead of GUI-native? Structured text that any tool could read and write. I used beads for several months. The approach worked: decompose features into small chunks, parallelize across agent sessions. But the tool introduced its own abstractions and terminology. A new mapping from whimsical terms to engineering concepts. I don’t want that. Give me the concepts I already know—issues, dependencies, priorities, blockers. And make them work better.The Case for More Automation
This got me thinking about the economics of software development. With coding agents getting better every month, the cost of generating initial implementations is dropping fast. The cost of validation, integration, and maintenance? Not so much. Consider the traditional cost model for shipping a feature:- A Product Manager to champion the feature
- A UX Designer to do user testing
- A Scrum Master to coordinate sprints
- A Dev Team to distribute the technical load
- A QA Team to test it
- A DevOps Team to deploy it
The Case for More Structure
There’s a counterargument worth considering. What does delegation mean in a traditional team? It means the freedom to focus on a small, specific component and take it to the finish line. A reduction in your cognitive load through distribution of information. This comes at a cost: information silos.The Telephone Game Problem
Consider “The Company”:Here at The Company, we do things a little differently. We are an agile, fast-paced, high-performance team, leveraging AI to ship products that make the world a better place!Sound familiar? PM Dave has a picture in his mind of what “done” means. He writes a JIRA issue based on the company template (hey, at least there’s some structure). Dev Sara reads the issue, chats with the team at standup, asks clarifying questions, assigns her name, transitions to “In Progress,” then gets to work. But there’s a problem: the picture in Dave’s mind does not look like the picture in Sara’s. The act of translation introduced signal degradation. Consider the conditional probability chain:
The same problem exists when prompting AI agents. Vague prompts produce vague
outputs. Structured prompts produce structured outputs.
Graph Traversal: Making Priority Mathematical
This is where ticket-rs comes in. Linking issues with blocking dependencies opens up graph algorithms for triage.PageRank
Important work (work that blocks or connects to other work) bubbles up to
the top. The same algorithm Google used to rank web pages, applied to your
backlog.
Critical Path
Identify the longest dependency chain. This is what determines your ship
date. Everything else is parallelizable.
Betweenness Centrality
Find the issues that connect disparate parts of your project. These are your
architectural linchpins.
Topological Sort
Generate a parallel execution plan. Respects dependency ordering, maximizes
concurrency.
tk triage runs graph analysis over your project and returns ranked recommendations. No more “oldest first” or naive priority sorting.
Context Engineering
There’s a term gaining traction: context engineering. The insight is simple. At every turn, a coding agent is a stateless function call. Context window in, next step out. The quality of the context is the only lever you have. ticket-rs is context engineering infrastructure. When Claude Code starts a session,tk prime loads the project graph into context: what’s ready, what’s blocked, what the critical path looks like, what to work on next. The agent doesn’t guess. It reads the graph.
while loop, you give the agent a context graph that evolves as the project does. The agent reads tk prime, picks the highest-impact ready issue, claims it, does the work, resolves it, and the graph updates. Next iteration gets fresh context automatically.
Why Local-First Matters
ticket-rs stores issues as markdown files with YAML frontmatter in a.tickets/ directory. No cloud sync. No SaaS subscription. No network latency.
tk triage, it completes in 14-21 milliseconds. Not 500ms waiting for a JIRA API. Not 2 seconds for Linear to respond.
Milliseconds.
Read More
The Fastest Ticketing System on Earth (Probably) — benchmarks and methodology
Getting Started
The Vision
- Dependency-aware — Graph analytics over your project’s dependency structure
- AI-native — Context-aware output for Claude Code, Cursor, and any coding agent. SessionStart hooks, MCP server, structured JSON.
- Git-backed — Issues live alongside your code, versioned and diffable
- Zero daemons — No background processes, no network calls, no latency