I last wrote about SpecKit in December of 2025 – an eon ago it seems. Since then, there’s been some epochal changes in how we use agents to write code – including Squad and other work orchestrating fleets of agents. In all this, it’s encouraging to note that SpecKit is moving forward in maturity level as well.

Over the past few days I’ve gotten a chance to get caught up with the latest evolution of SpecKit. This very popular project has undergone a significant pivot, moving to a modular “kit” ecosystem.

For teams looking to scale AI-assisted engineering without drowning in “token burn” or architectural drift, here are the key takeaways from the latest SpecKit developments.

Extensions and Presets

SpecKit has moved away from trying to be everything to everyone in its core code. Instead, it now uses a catalog model. Two big changes here have to do with extensions and presets:

Extensions: There are now over 80 community-driven extensions. (See the full list here – it’s getting quite long!) These allow you to add new commands (like visual GUIs or deployment triggers) without bloating the core engine. One example here is AI-Driven Engineering, which has a very cool workflow very distinct from the traditional SpecKit flow:

Presets: This is perhaps the most powerful update for enterprise teams. This is the way you can adopt the SpecKit workflow to your own methodology or use your own org standards. It’s actually a fairly complex stacked override system. So just as an example – there’s one preset (Lean Workflow) that’s very light on ceremony – just 3 files needed: spec, plan, and tasks.

But that’s just the beginning. There’s an interesting one on Accessibility, and another on Fiction Book Writing, or an enhancement to /clarify called VS Code Ask Questions. Anyway Presets look like a fantastic way to add your special spin to how SpecKit does its work.

Automating the SDD Cycle with Workflows

The introduction of Workflows transforms SpecKit from a manual CLI tool into an automated engine. Workflows chain the entire SDD cycle—from constitution to implementation—with built-in human-in-the-loop gates.

• Gated Approvals: The workflow will pause for review/approval/rejection at key milestones.
• Resumable Runs: If a process is interrupted, workflows maintain state, allowing you to resume exactly where you left off.
• Deterministic Automation: Unlike “Fleet” agents that can be unpredictable, workflows provide a step-based, procedural path that reduces unnecessary LLM hallucination.

I would say this is more for advanced / experienced teams – eliminating those gated steps might be a little jarring for some who are newer to using SpecKit / SDD.

Tools and Measuring the Cost of Quality with Token Analyzer

There’s a lot of cool SpecKit aligned content and tooling. For example there’s a visual GUI you can add:

But that’s not the best one I found. I’m working with quite a few enterprises as GitHub has made the pivot to Usage Based Billing, trying to control costs. I like this extension (?) very much – the Token Consumption Analyzer. This answers what often required lots of manual analysis – whether changing your model or prompt actually save tokens, and is it costing us in terms of quality?

Pro Tips for Better Implementation

Here are three immediate tactical shifts for your workflow:

• Stop Using Personas: Recent research suggests that telling an LLM “You are an expert architect” can actually degrade performance. It narrows the model’s focus too much. Instead, focus on the task and provide rich context.
• Manage Your MCP Servers: Tools like Azure DevOps or Figma MCP servers are great, but they add overhead to every request. Turn them off once you move from the specification phase to implementation to save on token costs.
• Positive & Negative Testing: Don’t just ask for “tests.” Explicitly require both positive and negative test cases. Also, avoid chasing fixed code coverage percentages (e.g., “must be 100%”), as the token cost to reach those final few percentage points often outweighs the value.

The Bottom Line

SpecKit is maturing into a professional-grade orchestrator that rewards context over complexity. Structured SDD can deliver working implementations even in complex existing codebases. I think the last two paragraphs of the excellent brownfield walkthrough sums it up quite nicely:

“The more interesting takeaway is the ceiling, not the floor. Even with a thin spec, a bare plan, and no analysis pass, the agents produced a running, end-to-end implementation that required only conversational follow-up to debug and verify. … For teams considering this workflow: the agents are only as good as the context you give them. Treat speckit.specify, speckit.plan, and speckit.analyze as investments, not formalities. The implementation will reflect the quality of the artifacts that precede it.”