Spec Kit + Plan Forge: Write the Spec, Enforce the Build

I'll be honest: Plan Forge exists because of Spec Kit.

Vibe coding was killing me. I'd fire up an AI agent, describe what I wanted, and watch it produce something that looked great for 30 minutes — then slowly disintegrate into a mess of scope drift, forgotten decisions, and "maybe I should start over." I was burning tokens and getting nowhere.

Then I found Spec Kit. And it clicked. Specification-based planning and agentic coding is like peanut butter and jelly — they're good on their own, but together they're something else entirely. Spec Kit taught me that the fix wasn't a better model. It was structure. Define what you want. Plan before you build. Stop letting the agent improvise.

As my ideas grew — as I learned what worked and what still broke even with good specs — Plan Forge started growing legs. What began as "I need more guardrails around my specs" became a full pipeline: scope contracts, auto-loading instruction files, independent review sessions, multi-model consensus, 18 MCP tools. Now it's laying down rubber in the quarter mile.

But the foundation — the insight that you need to specify before you build — that came from Spec Kit. And the two tools are genuinely better together than either is alone.

The Problem Both Tools Solve

Without structure, AI coding agents have three failure modes:

1. Scope drift — ask for a login page, get a login page plus a password reset flow plus an admin panel nobody requested
2. Architecture improvisation — the agent picks its own patterns, frameworks, and trade-offs without consulting your standards
3. Context amnesia — by session three, the agent has forgotten every decision from session one

Spec Kit addresses the first by forcing you to specify before you build. Plan Forge addresses all three by enforcing the spec during the build.

In v2.18, Plan Forge added Temper Guards to every instruction file — documented catalogs of the exact shortcuts that cause these three failure modes. When an agent thinks “this endpoint is internal-only, no auth needed” (architecture improvisation) or “I’ll add tests after the feature works” (scope drift into debt), the Temper Guard surfaces a concrete rebuttal. It’s a psychological defense layer on top of the structural gates.

What Each Tool Does Best

	Spec Kit	Plan Forge
Core philosophy	Spec-Driven Development	Hardened Execution Contracts
Primary strength	Defining what to build	Enforcing how it's built
Agent support	25+ AI agents natively	7 agents (Copilot, Claude, Cursor, Codex, Gemini, Windsurf, Generic)
Community	85K+ stars, 144 contributors, 40+ extensions	Growing, MIT licensed, 9 tech presets
Key mechanism	Slash commands (/speckit.specify, /speckit.plan)	Auto-loading guardrail files (18 per stack)
Execution model	Spec → Plan → Implement	7-step pipeline with validation gates per slice
Review approach	/speckit.analyze after building	Independent review in isolated session (Step 5)
Memory	memory/constitution.md	3-layer: Copilot Memory + session bridge + OpenBrain semantic search

Spec Kit has the bigger ecosystem and broader agent support. Plan Forge goes deeper on runtime enforcement and enterprise quality gates. Both are free. Both are MIT licensed. You genuinely can't go wrong with either.

The Combined Workflow

Here's where it gets interesting. Using both tools together gives you coverage that neither provides alone.

Phase 1: Define with Spec Kit

Start in Spec Kit's territory. Use its slash commands to build a structured specification:

# Set project principles
/speckit.constitution Create principles focused on code quality, testing, and security

# Define the feature
/speckit.specify Build a task management API with authentication,
                 role-based access, and real-time updates via WebSocket

# Generate an execution plan
/speckit.plan Use .NET 9, PostgreSQL, SignalR

# Break into tasks
/speckit.tasks

Spec Kit produces structured artifacts: specs/feature/spec.md, plan.md, tasks.md, and memory/constitution.md. These are well-defined, thorough, and leverage Spec Kit's strength at requirement elicitation.

Phase 2: Plan Forge Auto-Imports

When you start Plan Forge's Step 0 (Specifier), it scans the project for Spec Kit artifacts. If it finds them, it offers to import directly — no re-specifying needed:

• spec.md → maps to Plan Forge's feature specification section
• plan.md → becomes the execution contract baseline
• tasks.md → maps to execution slices in Step 2
• constitution.md → imports as PROJECT-PRINCIPLES.md

The handoff is seamless. Spec Kit's output becomes Plan Forge's input.

Phase 3: Harden and Enforce

This is where Plan Forge adds what Spec Kit doesn't: runtime enforcement.

The imported spec gets hardened into an execution contract with explicit forbidden actions, scope boundaries, and validation gates. 18 guardrail files auto-load during coding — security rules when editing auth files, database patterns when editing queries, testing standards when editing test files. The agent doesn't need to remember the rules. The rules are injected automatically based on what file is being edited.

Each slice (task) executes with build + test gates. The agent cannot proceed to the next slice until the current one passes. And when all slices complete, an independent reviewer — running in a fresh session with zero context from the builder — audits the entire implementation against the original spec.

Spec Kit is the architect's blueprint. Plan Forge is the building inspector who won't sign off until every beam is to code.

Shared Extension Ecosystem

Both tools support reusable extension packages, and the catalog format is compatible. Extensions marked speckit_compatible: true in Plan Forge's catalog work in both tools. The commands are parallel:

Action	Spec Kit	Plan Forge
Browse catalog	specify extension search	pforge ext search
Get details	specify extension info <name>	pforge ext info <name>
Install	specify extension add <name>	pforge ext add <name>

Build a multi-tenancy extension, a compliance extension, or a domain-specific guardrail package — it works in both ecosystems.

When to Use Which

Pick Spec Kit alone if: your team uses many different AI tools (not just VS Code), you want the largest community and extension library, and you prefer a lightweight spec-first methodology you can adopt incrementally. GitHub's backing means rapid iteration and strong long-term support.

Pick Plan Forge alone if: you want guardrails that auto-enforce during coding, you need 19 specialized reviewer agents, and you care about enterprise patterns — scope-contract locking, lifecycle hooks, deployment templates, and multi-model consensus (Quorum Mode).

Use both if: you want the full pipeline. Spec Kit's requirement elicitation and specification quality is best-in-class. Plan Forge's runtime enforcement and independent review is best-in-class. Together, you get specs that are both well-defined and impossible to drift from.

Honest Take

I built Plan Forge, so I'm biased. But I'll say it straight: Spec Kit has the bigger ecosystem, broader agent support, and GitHub's engineering team behind it. If I could only recommend one tool to someone starting out, the answer depends entirely on their pain point.

If your problem is "I don't know what to build" — start with Spec Kit. Its specification workflow is excellent.

If your problem is "I know what to build but the AI keeps drifting" — start with Plan Forge. Its enforcement pipeline is what you need.

If your problem is both — use both. They were designed for this.

Get Spec Kit →   |   Get Plan Forge →   |   Full integration guide →