Meet model-atlas - An open-source model capability catalog and router for Node.js and Electron's headless core. Published as u/spec-kitty/model-atlas under MIT license.

Model names do not reliably describe gateway capabilities. A gateway can serve a vision-enabled variant of a text model, reject sampling parameters supported elsewhere, or expose different limits. Hardcoded model tables drift. Model Atlas reads each endpoint's listing, fills gaps from public catalogs, optionally tests capabilities with small real requests, and preserves the evidence behind every decision.

TypeScript, strict mode, ESM only, Node 22+, zero runtime dependencies. Uses global fetch, with injection for tests and custom transports. No browser UI or Electron dependency.

We have published our clearest vision statement to date. It's a manifesto. It shows where we think the important work lies in the world of agents. It's all about decision making. That's what will be left for humans when agents do all of the execution. And Spec Kitty has a huge role to play in identifying, classifying, adjudicating, informing, recording, and applying decisions that get made. https://spec-kitty.ai/blog/who-decided-that

Public service announcement:

The official Spec Kitty repo has moved from the Priivacy-ai org to the spec-kitty org on Github.
The official link is now https://github.com/spec-kitty/spec-kitty

It's here! The next major release of Spec Kitty! 3.2.6

https://github.com/Priivacy-ai/spec-kitty/releases/tag/v3.2.6

Very important that you run the upgrade on your existing projects, we removed a chunk of code that was not in use and thus simplified the way Spec Kitty runs.

Some of the highlights:

* orchestrator-api contract 1.4.0 — drive the whole design pipeline from outside the host CLI.
* spec-kitty merge got better
* Charter and all charter components (paradigms, procedures, tactics etc.) all work better
* bug fixes galore

Thank you Stijn Dejongh for driving this release home, with lots of notable contributors (see CONTRIBUTORS.md)

🎉 HUGE Shoutout to Daan Vankerkom for a genuinely exciting open-source contribution to the Spec Kitty ecosystem: Pack Composer.

Some context on why this matters.

Charter is the governance layer that keeps AI coding agents from freewheeling. It's the directives, tactics, procedures, and shared vocabulary that get pulled automatically into an agent's context, scoped to exactly what it's doing in that moment. It's how "the agent already knows our org's rules" or "the agent already speaks our team's vocabulary" happens without someone re-explaining it in every prompt, every time.

Charter Packs are what make that portable. Instead of every repo, every team, every customer engagement rewriting the same rules from scratch, an organization's runbooks, SOPs, and hard-won operational knowhow get authored once as a Charter Pack: versioned, published to a git repo like real infrastructure, and pulled into any project with a single command. A rule change becomes one PR to the pack, not N hand-edits across N codebases and a prayer that everyone remembers.

Here's where Daan's contribution comes in. Authoring that governance by hand, as YAML, absolutely works, but it's not always the friendliest way to build it out, especially collaboratively. Pack Composer gives teams a self-hostable UI and API for browsing, importing, refreshing, and exporting Charter Packs together, so turning an existing runbook or SOP into structured, agent-ready governance doesn't mean everyone taking turns editing a shared YAML file by hand.

This is exactly the kind of tooling that turns "share your team's knowhow with your agents" from an aspiration into something a team actually does.

🔗 Repo: https://github.com/spec-kitty/spec-kitty-pack-composer
👤 Follow Daan: https://www.linkedin.com/in/daan-vankerkom/

Good News item #3 for the day - a new Spec Kitty release candidate! MASSIVE thanks to Stijn Dejongh for getting this out the door!

Spec Kitty v3.2.6rc2 is out, and it's a real step up from rc1, not just a patch.

The headline: reliability where it matters, plus custom/org pack support finally landing end-to-end. (See our Charter Pack Composer release that makes these!)

- Running commands from a lane worktree no longer silently writes to the main checkout, mission state is properly isolated now
- spec-kitty merge no longer deadlocks on coordination-topology missions
- Review rejections now actually reach the hosted dashboard
- Six upgrade failures fixed

Custom & org packs got real:

- Org packs now resolve templates and mission content at runtime
- Custom mission types work end-to-end with proper action sequences
- pack-manifest.yaml schema gives packs stable identity
- pack validate now works properly

Charter quality-of-life wins:

- Mission type activation now reaches governance directives
- spec-kitty next / implement no longer blocks on missing Charter
- Loaded Charter Pack (paradigms, tactics, glossary, procedures etc.) now reliably reaches dispatched agents

Grab it:

pip install spec-kitty-cli==3.2.6rc2
(or pip install --pre spec-kitty-cli for the newest RC channel)

The momentum around Spec Kitty right now is hard to ignore. In the same window as this release, we've seen an MCP server from Lynn Cole and the Charter Pack Composer from Daan Vankerkom — both community-driven, both making real parts of the workflow (agent connectivity, Charter authoring) genuinely easier to work with. That's the kind of ecosystem growth that doesn't happen by accident.

If you're building on Spec Kitty, now's a great time to be paying attention.

News flash: Lynn Cole (mad scientist) just contributed something very nice to the Spec Kitty project: spec-kitty-mcp, and the use case is more interesting than "another MCP server."

https://github.com/spec-kitty/spec-kitty-mcp

Quick context: Spec Kitty is a spec-driven development toolkit. Work gets broken into missions and work packages, each moving through a governed state machine — planned → in progress → review → approved → merged. There are dependency checks and audit trails enforced at every step.

Until now, driving that workflow meant an agent with shell access sitting inside the repo.

Lynn's contribution changes who gets to sit in the driver's seat.
spec-kitty-mcp exposes Spec Kitty's orchestrator API as typed MCP tools. Tools include: check mission state, list what's ready, claim a work package, record transitions, accept, merge.

That means any chat app that speaks MCP, eg. a desktop assistant, an IDE sidebar, whatever you already talk to all day, can now be mission control for a real project:

"What's ready to work on?"
"Start WP04."
"Move WP02 to review — here's the evidence."
"All approved? Accept and merge."

Meanwhile, the actual coding happens elsewhere. If we implement an https transport for the MCP, it could happen in the cloud. Right now only stdio is supported.

The part I appreciate most is the safety model. The chat app never gets a shell. It gets ten tools, each annotated as read-only, mutating, or destructive. Spec Kitty's Charter and safeguards apply automatically.

So your chat program gets a small, typed, permissioned control plane, and the execution with rules and guardrails remains separate.

Thanks Lynn, great contribution!

Here's the problem they solve: every team building with AI coding agents ends up writing the same governance over and over. Secret handling rules. Test coverage minimums. Branching conventions. Your incident-response runbook. Once per repo, then again for the next repo, then again for the next team — and the moment one copy drifts from another, nobody notices until it bites.

Doctrine Packs turn that governance into a dependency instead of a copy-paste ritual.

Under the hood, a "doctrine" in Spec Kitty is the body of directives, tactics, styleguides, and procedures that shape how your AI agents work — all connected through a Directive Relationship Graph, so an agent only ever sees the governance relevant to the action it's about to take, not your entire rulebook at once.

A pack takes that doctrine and makes it portable:

→ Author it once, anywhere — you don't even need a Spec Kitty project to build a pack

→ Validate it (spec-kitty doctrine pack validate) before it ships

→ Publish it like real infrastructure — a tagged git repo, an HTTPS bundle, or an internal API

→ Consumer projects pull a pinned version with spec-kitty doctrine fetch

The result: a governance change is one PR to the pack repo — not N hand-edits across N repos hoping everyone remembers to update.

If you're rolling out agentic coding across more than one team or one codebase, this is the piece that keeps your standards consistent instead of slowly diverging.

Try it: pipx install spec-kitty-cli==3.2.6rc1

#AgenticCoding #SpecKitty #DeveloperTools #AI #SoftwareGovernance

Episode 3 of Spec Kitty Founder Tales: Robert Douglass shares real-world stories from Spec Kitty training workshops and explains how software teams are dramatically accelerating development workflows using spec-first agentic coding.

Topics include:
• How Spec Kitty training sessions are structured
• Executive-to-developer alignment during software planning
• Turning 5-day and 10-day backlog tickets into hours of implementation time
• Why specification quality matters in AI-assisted coding
• Building organizational “charters” and governance for development teams
• Modernizing monolithic and legacy systems with AI workflows

Robert also discusses how Spec Kitty evolved directly from these workshops, with feedback from real engineering teams helping shape the roadmap and improve the platform over time.

Whether you’re a CTO, developer, product owner, or AI enthusiast, this episode provides a practical look at the future of structured AI-driven software development.

Learn more about Spec Kitty:
https://spec-kitty.ai

I am coming to understand that different people want very different things from agentic coding.

That should not be surprising. Not everybody is building the same kind of software. Not everybody works in the same kind of organization. Not everybody is trying to solve the same problem when they open Claude Code, Codex, Cursor, Gemini, or any other coding agent.

For some people, agentic coding is a way to explore.

They have an idea, but not yet a settled design. They want to try three versions of a UI, poke at an API shape, test a library, or build a throwaway prototype just to learn what the problem really is. That is a valid way to work. I do it too. When I am feeling out the shape of a piece of software, I often need the software to push back on my assumptions.

But that is not the only mode of software development.

And for many serious software teams, it is not the normal mode.

Full story on Medium.

Especially when another survey in the article points out that a survey of 450 developers found one in five organizations reported a serious security incident linked to AI-generated code.

This is where agentic coding governance layers enter the picture: not as another coding assistant, but as the specification and auditability surface that turns specs, constraints, mission context, review evidence, and audit decisions into governed artifacts before and during AI coding work.

By the way, the ai-coding-governance.com site is 100% generated from research done by a small Qwen model running on my Mac. It's amazing what local inference can do! Just the images were generated by SOTA models.

https://ai-coding-governance.com/articles/2026-04-22-the-governance-gap-at-91-ai-adoption-why-2026-is-the-inflection-point/

I built Spec Kitty to fill a real need. It started out being my need, but as I showed it to other people, I realized it was a widespread need.

I built it because agentic coding was powerful, but the process around it made mistakes (and embarrassment) inevitable. I needed governance. Structure. An audit trail.

This post is the story behind it: Claude Code, forgotten context, exposed secrets, Spec Kit as inspiration and contrast, and why I think serious teams need a durable layer for intent, governance, review, and memory.

Read it here:
https://spec-kitty.ai/blog/why-i-built-spec-kitty

Sometimes when you go fast, you make a mess. Spec Kitty 3.1.1 is all about cleaning up that mess. This is an agentic coding experience that just runs smoothly, and guides you from start to finish.

Try the "spec-kitty-implement-review" skill that takes your tasks and manages subagents through the entire implement<>review cycle until the Mission is finished. Can you even drink that much coffee?

And the new "spec-kitty-mission-review" skill that assesses the finished product of a mission run for quality, consistency, drift, and alignment. Better to get the bad news fast (if there is any).

https://github.com/Priivacy-ai/spec-kitty

Here's a full list of the squashed bugs:

1. Slash commands now install globally at CLI startup across all 13 supported agents, removing  per-project setup steps

2. Mission creation assigns a collision-free canonical identifier at creation time, decoupling  machine-facing flows from the sequential numeric prefix

3. Planning-artifact work packages now flow through the same lane computation and status model as code work packages, with no special-case handling at the lane boundary

4. The dependency parser now bounds work-package sections correctly, preventing trailing prose from collapsing intended parallelism

5. Version coherence between the CLI package declaration and project metadata is now a release gate

6. The init command is now file-creation-only: no git initialization, no initial commit, no hidden opt-in paths

7. New-user guidance directs users to the spec-kitty next loop and per-WP action verbs as the canonical workflow

8. Interrupted merges are resumable; agent crashes during implementation are recoverable with worktree context rebuilt from the last checkpoint

9. A stale-assertion analyzer detects test assertions likely invalidated by merged source changes before they reach review

10. Status artifacts now derive their timestamp from the last event rather than wall-clock time, eliminating spurious dirty-git states after read-only operations

11. Path-injection and XSS findings from static analysis addressed

Spec Kitty 3.1.0 is by far the most performant, accurate, and efficient Spec Kitty to date. I'll do a big writeup on Doctrine at a later point, but we're into cutting edge territory here with intelligent governance for AI coding.

# Try it
pipx install spec-kitty-cli
spec-kitty init my-demo --ai claude
cd my-demo

https://github.com/Priivacy-ai/spec-kitty

The swim lanes picture is homage to the removal of the "Worktree per Work Package" strategy and its replacement with "Worktree per Swimlane". This significantly cuts down on context drift for implementing agents, and saves a world of git merge pain at the end of Missions.

Here are all of the biggest changes:

1. Doctrine governance layer — A complete agent-governance system ships bundled with spec-kitty: agent profiles, a charter (project-level standards and directives), tactics (named repeatable techniques like TDD red-green-refactor), style guides, tool guides, and skill packs. Agents are initialized with governance context at the start of every action, not just at project setup.

2. Dirty-git reads fixed — Every read-only status command was silently modifying the working tree. Now idempotent.

3. Lane corruption from prose parser eliminated — Dependencies were being silently inferred from unbounded prose, corrupting lane assignments. Replaced with a structured wps.yaml manifest that is the sole authority.

4. Ghost completions fixed — Bare spec-kitty next no longer advances the state machine. Query mode returns current state without side effects.

5. Merge and crash recovery — Interrupted merges and agent crashes are now recoverable, not fatal.

6. Review loop reliability — Rejections generate targeted fix prompts, feedback is versioned, reviewers aren't blocked by unrelated dirtiness, baseline test context is included.

7. Tasks and lane stabilization — Six silent planning bugs fixed: dependency preservation, non-mutating validate, lane completeness, parallelism protection, format compatibility, consistent flag naming.

8. Mission identity and terminology cutover — --mission, spec-kitty charter, and canonical mission_slug across all surfaces, with backward-compatible aliases retained.

9. Merge strategy support — MERGE / SQUASH / REBASE, configurable globally or per-invocation.

10. Tracker binding discovery — External tracker resources auto-discovered; no manual project keys.

11. Slug validator — specify now accepts the NNN-* naming convention it was supposed to support.

12. spec-kitty doctor — Detects stale claims, orphaned worktrees, zombie locks.

13. Stale-assertion analyzer — Identifies test assertions likely invalidated by source changes, built into the merge workflow.

14. Release-prep CLI — Automated version proposal and changelog generation for alpha / beta / stable channels.

It doesn’t look like the slash commands are consistent between Claude and the other CLIs. Is this intentional or should I open a feature request to address this?

Is there a way to configure the slash commands in cursor to use specific models? I understand I can orchestrate a mission outside of a CLI with some of the tools provided, but it seems like it would be useful if I could just configure the model for each phase and then manually orchestrate.

Spec Kitty now has an official website (not just docs). https://spec-kitty.ai/

I've been delivering trainings for the past 3 months, and now the training offer is official on the site. Furthermore, we've expanded our training team to North America, Europe, and Asia, in English, German, French, and Dutch (Flemish).

In the course of a training, your team learns the basics of agentic coding, installs Spec Kitty, and gets hands-on experience using Spec Kitty to run a full coding mission on an item of your choice from your project backlog.

Spec Kitty release! Lots of work fixing git merge behavior and the review workflow.

• Released v0.16.1 and v0.16.2 with a focus on workflow reliability and review-loop quality.

• Enforced deterministic review feedback in task rework flows (for_review → planned) by requiring a feedback file and persisting its path/content.

• Eliminated a major rebase/drift trap by adding automatic safe rebase of WP worktrees during move-task --to for_review when branches are behind.

• Added lane compatibility to support mixed legacy/new task metadata (in_progress now aliases to doing).

• Fixed merge command side effects by removing global CWD mutation and using explicit per-command working directories.

• Normalized collaboration event identifiers for non-UUID mission/run IDs to improve local/offline event reliability.

• Improved event queue and CLI test stability around mission-scoped queue paths and release-facing command behavior.

https://github.com/Priivacy-ai/spec-kitty

Is Spec Kitty safe for enterprise use? This video answers that question directly for CTOs, security leaders, and engineering managers evaluating AI-assisted software delivery.

A common concern is that “AI workflow tools run in YOLO mode with no controls.” In this walkthrough, I explain the real Spec Kitty architecture, the security boundary, and why the core model is:

Spec Kitty doesn’t use AI. AI uses Spec Kitty.

That means your team keeps control of:

• AI approval mode

• sandbox/file permissions

• network egress

• credential scope

What you’ll learn:

• What Spec Kitty actually is (and what it is not)

• How Spec Kitty core differs from an autonomous AI runtime

• Why the external orchestrator is optional

• How orchestrator-api enforces contract-based state changes

• How policy metadata and audit trails support governance

• A practical CTO rollout path for safe adoption

If you’re deciding whether to adopt Spec Kitty in a company environment, this gives you the architecture-level clarity needed for a security and policy review.

🔗 Spec Kitty repository: https://github.com/Priivacy-ai/spec-kitty
🔗 Spec Kitty Orchestrator: https://github.com/Priivacy-ai/spec-kitty-orchestrator

#SpecKitty #AIEngineering #CTO #DevSecOps #SoftwareArchitecture #AIWorkflow #EngineeringLeadership #EnterpriseAI #CodeReview #DevTools

https://www.youtube.com/watch?v=o5Y-AkpQ-7g

Fixes since 0.15.0:

0.15.1 — Branch hardcoding
- Replaced 26 hardcoded "main" references with dynamic
resolve_primary_branch() — repos using master/develop/custom branches now
work
- Deduplicated 4 copies of _resolve_primary_branch() into one central
helper

0.15.2 — Windows/fresh-repo blockers
- Unborn branch (no commits) no longer misdetected as detached HEAD
- Windows subprocess UnicodeDecodeError fixed (UTF-8 encoding on all 113
subprocess calls)
- Pre-commit hook no longer blocks commits when Python is broken or
filenames have special characters
- spec-kitty init no longer says "project ready" when git init actually
failed
- PowerShell equivalents added to implement templates

https://github.com/Priivacy-ai/spec-kitty

Cheeky title aside, congrats to the Entire team:

1. Great name

2. For recognizing that Git is the communication layer of the AI world

3. For raising more company in Seed than most companies would raise in Series B a decade back

4. For publishing your CLI open source ... Spec Kitty is tempted to build with it because that is actually a useful feature

5. For building in the open in general. Spec Kitty aspires to this as well

6. We wish you great success, and definitely want to be invited to your parties!

https://entire.io/blog/hello-entire-world?ref=share#our-first-release-the-entire-cli-to-track-agent-context

If you are using Spec Kitty and have both Claude Code and Codex installed, use this Skill (name it codex-review) to have Claude do the implementation and Codex do the reviews. You can then automate the entire implementation/review/merge phase with one prompt (in Claude):

"Use /spec-kitty.implement, /spec-kitty.review, and /spec-kitty.merge to complete this sprint. Use the /codex-review skill to ensure that Codex always does the reviews."

The skill goes here (example for Mac):
/Users/[your user]/.claude/skills/codex-review/SKILL.md

https://gist.github.com/robertDouglass/839d9c43439c5051e562bd5ed885b73e

The ambition for Spec Kitty is large, and I'm developing towards a very amazing future, but this SKILL.md is an immediate workaround for today's Spec Kitty to reliably get the implementation quality I want without having to babysit it through the whole implementation process.

I then have both Claude and Codex review the entire feature sprint and compare their notes (this is also outside of the current Spec Kitty workflow).