GitHub Spec Kit Defines the Plan. Who Enforces the Architecture?

Spec Kit Brings Structure to AI-Assisted Development

Spec Kit is a toolkit for spec-driven development, and its central move is to make the process explicit. Instead of one long prompt, you run an ordered set of commands. You establish a constitution with /speckit.constitution, describe what you want with /speckit.specify, produce a technical plan with /speckit.plan, break it into work with /speckit.tasks, and build with /speckit.implement. Optional steps like /speckit.clarify and /speckit.analyze tighten the loop. It is a serious, well-designed approach to spec-driven development, and it is popular for good reason.

The constitution is the interesting part. Stored in .specify/memory/constitution.md, it holds your project’s foundational principles — the rules meant to guide every later phase so decisions stay consistent. On paper this looks like governance. You write the principles once, and every specification, plan, and implementation is supposed to respect them. That is exactly the right instinct. The question is what “respect them” means mechanically.

The Constitution Matters, but It Is Agent-Interpreted

Here is the seam. The constitution is a Markdown file the coding agent reads as context and is instructed to follow. It shapes the agent’s behavior through prompting, and prompting is probabilistic. A principle sitting in the context window is an input to generation. It is not an independent gate that inspects the output. When the agent writes the plan, or writes the code, nothing outside the agent re-reads the constitution and blocks a change that breaks it.

This is not a flaw in Spec Kit. It is the nature of a document that guides an agent. A rule the model is told to obey and a rule a separate system enforces are different kinds of object. The first depends on the model attending to it, remembering it across a long task, and applying it correctly to a specific edit. The second holds regardless of what the model was thinking. Spec Kit gives you the first. Governance before generation as an independent check is a distinct capability, and a constitution in the prompt does not provide it.

Feature Specifications and Architectural Decisions Are Different Artifacts

The deeper point is that Spec Kit’s primary unit — the feature spec — answers a different question than the one architecture asks. A feature spec describes what to build now. An architectural decision describes what must remain true while you build it. Consider a concrete case.

The feature spec says: add asynchronous invoice processing so large batches do not block the request. That is a clear, well-formed spec. Spec Kit will help the agent plan it and implement it.

The architectural decision says something the spec never mentions: all async jobs must use the existing worker service on SQS. Do not introduce another queue. That decision is not about this feature. It predates it and outlives it. It is a project-wide constraint recorded because a second queue technology would fracture operations, monitoring, and on-call. The feature spec is silent on it, and reasonably so — a spec is scoped to the change, not to the standing invariants of the system.

These two artifacts have different lifetimes and different owners. A feature spec is written, implemented, and retired. An architectural decision is durable; it constrains every feature that comes near it. Keeping executable architectural intent in a per-feature spec conflates the two. The decision needs to live somewhere durable and be checked on its own terms.

Where Architectural Violations Still Happen

Now watch how drift enters a perfectly good Spec Kit workflow. The spec is fine. The constitution even mentions using approved infrastructure. The agent plans the async invoice feature, and while implementing it, reaches for the tool it has seen most often in training:

• It adds Redis and BullMQ to run the invoice jobs, because that is a common, idiomatic async pattern — but the approved queue is SQS, and now the repo has two queue technologies.
• It calls the billing database directly for a status write instead of going through the billing service’s API, quietly crossing a service boundary the architecture draws deliberately.
• It pulls in a second auth library for a token-signing helper because it was convenient, next to the one the rest of the codebase already standardized on.

Each of these produced working code. Each satisfied the feature spec. The constitution was in context the whole time. Drift happened anyway, because the constraint that mattered lived as a principle the agent was asked to honor, not as a check the change had to pass. This is the same gap that runtime verification does not close: tests confirm the invoices process; they say nothing about which queue processed them.

Spec Kit’s Extension Model Is the Integration Point

Spec Kit is not a closed system, and this is where the two layers meet cleanly. It ships an extension model: extensions add new capabilities and commands, presets override templates to enforce organizational standards, bundles assemble role-based sets, and a community catalog distributes all of it. There are lifecycle extension points around planning and implementation where additional steps can run.

That model is the natural home for an architectural check. A Spec Kit extension could invoke an independent decision-checking step after the plan is produced and again around implementation — not to rewrite the constitution, but to verify the generated plan and code against durable decisions the constitution references. The point is not that Spec Kit lacks structure. It is that the structure has a documented seam where a separate verifier belongs.

What an Architectural-Guardrail Layer Should Add

Whatever fills that seam should do a specific set of things, and it should do them independently of the agent doing the writing:

1. Keep durable decisions separate from feature specs. Architectural decisions are recorded as structured, standing constraints, not folded into whichever spec is active today.
2. Retrieve only the relevant decisions. A change to invoice processing should surface the queue and service-boundary rules, not every decision in the project.
3. Check both the plan and the edits. Catch the second-queue choice in the plan if possible, and catch it again at the edit if it slips through.
4. Return a deterministic verdict that names the violated decision. Not “this looks off” but “this introduces BullMQ; ADR-014 requires SQS.”
5. Distinguish warn from block. Some decisions are advisory; some must stop the change. The layer should support both, with reviewable evidence attached.
6. Work across agents. The check is model-independent, so it holds whether the code came from Spec Kit’s agent, a different assistant, or a human.

These are verification contracts, and they are deliberately separate from generation. That separation is the whole value: a check that depends on the same model it is checking is not an independent check.

How Mneme Complements Spec Kit

Mneme is that layer, and it is complementary to Spec Kit rather than a replacement for it. The division of labor is clean. Spec Kit structures intent and drives the workflow. Mneme keeps the durable decisions and checks proposed changes against them at the execution boundary. In practice the two run together like this:

1. Spec Kit runs its normal flow: constitution, spec, plan, tasks, implement.
2. Mneme loads the project’s recorded ADRs as structured constraints, kept separate from the feature spec.
3. Around planning, Mneme can check the generated plan and flag a decision the plan would violate before any code is written.
4. At implementation, the Claude Code PreToolUse hook intercepts each Edit, Write, and MultiEdit. When a strict-mode check finds a violation — the second queue, the crossed boundary — the hook exits with code 2 and blocks the edit, returning the specific decision that was broken so the agent can retry compliantly.
5. The final diff is reviewed against the same decisions, so nothing that slipped past edit-time is missed.

Be clear about the limits, because honesty is the point of a governance layer. Mneme’s retrieval depends partly on file-path relevance, so a decision can be missed if a change touches files the retrieval did not associate with it. The edit-time hook is a strong first line of defense, not a full repository audit — it checks the change in front of it, which is why the plan check and the final-diff review matter alongside it. And to be precise about status: Mneme does not ship a Spec Kit extension today. The Claude Code PreToolUse hook is real and shipping. The Spec Kit integration is proposed — the extension model provides the point where it would attach.

Two Forms of Intent

The clean way to hold both tools in your head is to separate two kinds of intent. There is feature intent: what to build now, captured by the spec. And there is architectural intent: what must remain true while you build it, captured by the recorded decisions. Spec Kit is built around the first. Mneme is built around the second. They are not competing for the same job.

Use Spec Kit to give AI-assisted work a spine. Add an architectural governance layer so the intent the spec never encodes still holds when the code lands. This is the tool-specific version of a general argument: spec-driven development still needs governance, and the same seam appears in Google’s take on spec-driven development too. The plan tells the agent what to do. A separate layer confirms the agent did not quietly change the architecture on the way.