The twelfth entry in a series exploring Spec Kit and what it can do for spec-driven development.
At the end of Part 11 I split the road ahead in two and paid out only half of it. That post was about your move — the small first lap, the optional ladder above it — and I said the other half, “where the project is heading, what the maintainers are building next, which of the community clusters from Part 8 get pulled inward the way converge was,” was “deliberately left for another day, because it is speculation and this post was meant to be actionable.” This is that other day. Two posts ago, Part 10 asked the same question in the same breath — “where does Spec Kit go from here, and where do you go from here?” — and I have now answered the second half twice. This post is the first half, finally, and I want to be honest up front about what kind of post it can be.
It cannot be a schedule. I do not have a roadmap I want to recite here, partly because the honest answer is that the community keeps telling me what matters faster than I could plan it. So this is not a list of dated features. It is something more useful and more durable — the shape of the road, read off the architecture the last eleven posts described. Because the interesting thing about how Spec Kit is built is that it makes its own future fairly legible. You do not have to guess where it goes. You mostly have to read what it is already doing and notice which way it points.
The single most important thing I said about direction, I said in Part 8 and then walked past: a healthy extension ecosystem is a roadmap that writes itself. Every cluster of community extensions is the community telling the core team, in the most credible currency there is — working code someone bothered to publish — exactly where the reference process asks the most of you. No survey produces a list that honest, because these are the frictions people cared enough to fix on their own time.
And the loop has already closed once, visibly, in a way that turns this from a nice metaphor into a repeatable mechanism. The reference sequence used to end at implement, and the gap right after it — does the code actually match the spec? — was the most-cited criticism of the whole tool. Dozens of authors independently converged on the same missing step: a post-implementation reconcile loop. Then the core adopted it, as /speckit.converge, an opinionated ninth step that runs after implement and drives the code back toward the artifacts. The community proved the gate as extensions; afterward the maintainers promoted the pattern into a first-class command.
That is the template. So the honest way to forecast the road ahead is not to interview the maintainers — it is to ask which clusters are growing the way the convergence cluster grew before it was pulled inward. The catalog is a heat map, and the hot regions are the roadmap.
Read that way, Part 8’s field guide is not a survey of the past. It is a shortlist of candidates, and three of them stand out because they share convergence’s exact signature: many independent authors, solving the same problem, in slightly different idioms, because the core leaves a gap they all feel.
The first is the brownfield on-ramp. Spec Kit already can work against an existing codebase, but doing it well costs you a careful constitution prompt every time, and the community has paid that ergonomics tax down with a whole cluster of extensions that pre-load the “here is a large existing system, respect it” framing. That is precisely the shape convergence had before promotion: a capability that technically exists but asks too much of the user, patched by many hands. If any cluster is next in line to be smoothed into the core, this is my bet.
The second is trackers that are not GitHub. /speckit.taskstoissues speaks GitHub fluently, and a real fraction of the community speaks Jira, Linear, Azure DevOps — something else. The extensions that bridge those are not exotic; they are the same “turn tasks into tracked work” idea aimed at a different backend. The core’s honest move here is probably not to ship a Jira command — it is to generalize the seam so the integration layer from Part 4 can translate task breakdowns into any tracker the way it already translates commands into any agent.
The third is the cost meter. The core is silent on token cost; the community put a meter on it. As spec-driven runs get automated into workflows that fire in CI, “what did this run cost me” stops being a curiosity and becomes an operational number people need. A cluster that starts as convenience tends to get pulled inward exactly when it crosses into operational necessity, and automation is what pushes it across.
I want to be careful with the word “bet.” None of these is promised, and I would rather be pushed than trusted here. But the mechanism that will decide it is not a maintainer’s whim — it is which of these clusters keeps growing, and that is a thing you can watch as easily as I can.
There is a direction that is not on the heat map at all, because it is not a gap the community can fill from outside. Twelve posts in, I have described five distinct primitives — extensions, presets, integrations, workflows, and steps — plus bundles that compose them and catalogs that distribute them. Each one is, I think, well-designed in isolation. The risk the whole series has been quietly accumulating is a real one: that the kit ends up feeling “like a pile of powerful primitives” rather than one coherent thing.
That is the maintainers’ work in a way the community’s cannot be, and I think it is the most important direction of all. Every post in this series pointed at the same instinct — compose, don’t accrete — and the road ahead is where that instinct has to be turned on the toolkit itself. Five primitives governed by one catalog model is already a real act of restraint; most toolkits would have grown five distribution systems and I keep being glad this one grew one. But governance being unified is not the same as the experience being coherent, and the honest next chapter is less about adding a sixth primitive and more about making the five already there feel like they were designed by one hand for one journey. If Spec Kit ships nothing new for a while and instead makes the seams between these layers disappear, that would not be stagnation. It would be the most on-brand thing the project could do.
There is one direction that runs the opposite way — outward, not inward. The cluster in Part 8 that surprised me most was the one that has nothing to do with programming: a fiction-writing preset shipping 26 templates and 34 commands, screenwriting with beat sheets and Fountain export, game-narrative pipelines with branching dialogue. None of them touch a compiler, and every one of them works, because the specify-plan-implement skeleton was always a general discipline — intent, refinement, ordered execution — and “spec” and “task” were always more generic than “software.”
I do not think the core team’s job is to go write a novelist’s toolkit. But the existence of that cluster is a standing question the project has to answer eventually: is Spec Kit a tool for building software that happens to generalize, or a general discipline for intent-driven work that happens to have started with software? The kit of processes thesis from Part 6 leans hard toward the second reading, and the road ahead is partly a decision about whether to lean into that — to treat the non-code communities as first-class citizens rather than delightful accidents. My instinct is that the honest thing is to keep the core narrowly excellent at software and let the catalog carry the frontier, but I hold that loosely, and it is exactly the kind of question I would like to be argued out of.
If there is one direction I would call non-negotiable, it is the one the series kept circling and never resolved: the trust boundary. A shell step in a workflow runs a local command with your privileges, in no sandbox. A community extension is code a stranger wrote and you installed. The project has been admirably honest about this — it declines to add a requires.permissions field precisely because a permissions list would imply a sandbox that does not exist, and Spec Kit would rather reject the field than lie about enforcing it. The verified badge means the catalog entry is well-formed, not that its code is harmless.
Honesty is the right first move, but it is not a destination. The community docs already lean on a real and unglamorous form of contribution — someone reads a stranger’s source and files an issue when the info says read-only but the code writes to specs/. That human trust layer works, and it does not scale on its own. The most valuable thing the maintainers could build in the next stretch is not a feature at all in the usual sense; it is more machinery that makes the trust boundary legible — clearer provenance, better ways to see what an artifact actually touches before you run it, tooling that helps the “read the source” discipline instead of just recommending it. It is the least flashy direction on this list and, I suspect, the one that matters most as the catalog crosses from a hundred entries into a thousand.
I have ended nearly every post in this series with what I appreciate about the design, and the thing I appreciate about the road is the same thing I have appreciated about every layer: it is legible because the architecture externalizes it. A project whose future depends on a private roadmap in a maintainer’s head is opaque by construction — you find out where it went when it gets there. A project whose future is written in a public catalog, where the clusters that grow are the features that get promoted, is one you can read the direction of without any special access. That is why I could write this post at all. I am not revealing a plan; I am reading a heat map that is as visible to you as it is to me.
And it keeps faith with the same principle as everything else. The maintainers’ job, on this model, is mostly restraint plus promotion — watch which clusters grow, pull the winners inward, make the seams disappear, and resist adding a sixth primitive when the honest work is making the five cohere. It is a smaller, more patient job than “have a visionary roadmap,” and I think it is the right one for a toolkit whose whole thesis is compose-don’t-accrete. The road ahead, in other words, looks a lot like the road behind: the community proposes, the catalog measures, the core promotes, and the whole thing stays legible enough that a blog post can trace it.
That is the architecture arc closed — twelve posts from a bundle that installs a whole process in one command, down to the atom of a custom step, and now out to the shape of where all of it is heading.
It is worth ending where the project itself starts. Spec Kit’s README still files its ambitions under a heading it has never quietly renamed — “Experimental Goals” — and states outright that spec-driven development is meant to be “a process not tied to specific technologies, programming languages, or frameworks,” in service of a one-line promise: build high-quality software faster. Every direction in this post is really just that experiment still running. The non-code frontier is the technology-independence hypothesis taken to its logical, delightful end. The brownfield cluster is the “Iterative Enhancement” phase the README already names, asking to be made smoother. The coherence work is what “faster” has to mean once you have enough powerful primitives to slow a newcomer down. Reading the road off a public catalog is not a detour from those goals; it is the most honest way to pursue goals that still call themselves experimental — you do not schedule the results of an experiment, you watch what it produces and follow. Where it goes next is, as always, partly yours to decide, because the catalog you contribute to is the roadmap. If there is a cluster you think is next in line, a coherence seam that annoys you, or a direction you think I have read wrong, send an email to blog (at) manorrock.com and push me on it.
And if the road is a heat map and the catalog is the chart, then the rest writes itself: hoist a Voyage Manifest, draw up a Battle Plan, hand out the Crew Assignments — and add your name to the map so the next sailor finds the passage you cut. The roadmap is crewed, not commanded. Grab an oar. Be the pirate! 🏴☠️
Further reading: the Spec Kit repository, the Community overview that this post treats as the real roadmap, What is Spec-Driven Development?, Part 11: Where Do You Go From Here?, Part 10: Steps, Part 9: Workflows, Part 8: A Field Guide to the Community, Part 7: Catalogs, Part 6: From Spec to Kit, Part 5: The Spec-Driven Process, Part 4: Integrations, Part 3: Presets, Part 2: Extensions, and Part 1: Bundles.