Intent Kit: A Simpler Alternative to Spec Kit for AI-Driven Software Development
- Mark Kendall
- 10 minutes ago
- 7 min read
Intent Kit: A Simpler Alternative to Spec Kit for AI-Driven Software Development
Absolutely. I pulled the current README for Intent Kit and compared it with the current Spec Kit workflow. Here’s a Wix-ready article that gives Spec Kit proper credit while making the case that Intent Kit is deliberately optimizing for a simpler developer experience.
Intent Kit: A Simpler Alternative to Spec Kit for AI-Driven Software Development
AI-assisted software development is quickly moving beyond prompting.
The question is no longer:
“Can AI generate code?”
We already know it can.
The more important question is:
How do we turn business intent into software repeatedly, safely, and with evidence that the requested outcome was actually delivered?
GitHub’s Spec Kit has made an important contribution to that conversation.
Now there is another approach worth considering:
Intent Kit.
Define Intent → Compile Action → Deliver Impact
The objective isn’t to replace the coding agent.
It is to give the coding agent a better operating model.
First: Spec Kit Deserves Credit
GitHub’s Spec Kit helped establish an important principle: developers shouldn’t simply throw prompts at increasingly powerful coding agents and hope for good results.
Software development needs structure.
Spec Kit provides exactly that through a structured Spec-Driven Development workflow.
Its core process includes steps such as:
Constitution → Specify → Plan → Tasks → Implement
with optional clarification, analysis, checklists, extensions, presets, bundles, and other capabilities.
That is powerful.
Spec Kit also supports more than 30 AI coding agents and has developed a significant open-source ecosystem around Spec-Driven Development.
The philosophy behind it is something we strongly agree with:
Understand what should be built before generating the code.
Intent Kit simply approaches the developer experience from a different direction.
The Question Behind Intent Kit
While experimenting with AI-assisted development across tools such as Claude Code, Cursor, Copilot, and other coding agents, we kept coming back to one question:
How much of the methodology does the developer actually need to manage?
Developers ultimately want to build features.
They don’t necessarily want to become experts in a new AI development methodology, remember a long sequence of commands, or manually orchestrate every stage of an AI workflow.
What if most of that machinery could sit underneath the developer experience?
That became one of the central ideas behind Intent Kit.
Instead of asking the developer to manage the process, Intent Kit starts with something much simpler:
/intent Add customer billing history
The developer manages the intent.
The system manages much of the process required to turn that intent into working software.
What Is Intent Kit?
Intent Kit is a lightweight operating layer that sits between human intent and an AI coding agent.
The developer defines the desired outcome.
Intent Kit helps the agent move through:
Intent
↓
Understand Repository
↓
Clarify Only If Necessary
↓
Plan
↓
Implement
↓
Test
↓
Build
↓
Verify Acceptance Criteria
↓
Capture Evidence
That final step is important.
The objective isn’t:
“The AI generated some code.”
The objective is:
“The requested outcome was implemented and verified.”
That is a very different definition of done.
One Feature. One Intent.
Intent Kit organizes work around an Intent.
For example:
.intent/intents/billing-history/
├── intent.md
├── plan.md
└── evidence.md
The most important artifact is intent.md.
It describes things such as:
desired outcome
business value
scope
exclusions
constraints
acceptance criteria
The intent becomes the contract between the requested outcome and the implementation process.
The AI coding agent can determine much of the technical implementation from the repository itself.
Repository Awareness Comes First
This is another important design decision.
Intent Kit was designed for real repositories—not just greenfield demonstrations.
When initialized, it examines the existing repository and discovers things such as project conventions and verification commands.
The principle is simple:
Understand the system before changing the system.
That matters enormously in enterprise development.
Most enterprise software work isn’t creating brand-new applications.
It’s changing existing ones.
It’s adding an API to a 10-year-old service.
It’s modifying billing behavior.
It’s extending authentication.
It’s changing a React screen connected to multiple backend services.
It’s working inside a monorepo with years of architectural decisions.
Intent Kit therefore assumes the repository already contains valuable context.
The coding agent should discover that context before deciding how the feature should be implemented.
Intent Kit vs. Spec Kit
The two approaches have significant philosophical overlap.
Both reject unstructured “vibe coding.”
Both recognize that AI development needs persistent artifacts.
Both separate requirements from implementation.
Both introduce planning before coding.
Both support AI coding agents.
Both can support organizational standards and governance.
The biggest difference is emphasis.
Spec Kit exposes a rich Spec-Driven Development process.
Intent Kit attempts to hide much of that process underneath a smaller developer interface.
Spec Kit gives developers explicit commands for stages such as specification, planning, task generation, clarification, analysis, and implementation.
Intent Kit deliberately keeps its command surface much smaller.
For many developers, the normal starting point becomes simply:
/intent <what I need>
That doesn’t mean the planning, verification, standards, and governance disappeared.
It means they moved underneath the developer experience.
Why Intent Kit Might Be Better for Some Teams
Spec Kit may be the better choice when a team wants a rich, explicit specification methodology with a mature ecosystem of extensions, presets, workflows, and agent integrations.
Intent Kit may be worth considering when the priority is different:
Get developers from business intent to verified software with as little ceremony as possible.
The difference can be summarized this way:
Area
Spec Kit
Intent Kit
Primary concept
Specification
Intent/outcome
Developer experience
Explicit structured workflow
Simplified intent interface
Planning
Explicit phase
Managed beneath intent workflow
Repository awareness
Supported
Central design principle
Verification
Workflow capabilities
First-class delivery requirement
Evidence
Available through workflow/process
Core delivery artifact
Agent support
30+ integrations
Tool-agnostic architecture; Claude Code first-class
Enterprise standards
Extensions, presets and bundles
Standards built beneath developer workflow
Philosophy
Specs drive implementation
Intent drives verified outcomes
Optimization
Process depth and extensibility
Developer simplicity and outcome delivery
Neither philosophy requires the other one to be wrong.
They’re solving closely related problems at different levels of abstraction.
Don’t Make Every Developer an AI Methodology Expert
This may ultimately be the biggest philosophical difference.
An enterprise might eventually have:
architecture standards
security standards
approved MCP servers
reusable skills
specialized agents
verification hooks
CI/CD controls
audit requirements
cost controls
outcome metrics
Developers shouldn’t have to understand every component before they can deliver a feature.
Instead, imagine:
Developer
↓
/intent Add customer billing history
↓
INTENT KIT
↓
Architecture Standards
Security Standards
Approved MCP Servers
Reusable Skills
Approved Agents
Verification Hooks
CI/CD Controls
Audit Evidence
Cost Controls
Outcome Metrics
The developer experience remains simple.
The platform carries the complexity.
That’s much closer to how enterprise platforms traditionally succeed.
We don’t ask every developer to understand Kubernetes internals before deploying an application.
Why should we require every developer to understand the internals of an AI engineering operating model before using an AI coding agent?
Don’t Spend Any Token Before It’s Time
Intent Kit also reflects another principle we’ve been exploring in Intent-Driven Engineering:
Don’t spend any token before it’s time.
AI agents consume tokens when they explore repositories, reason about ambiguous requirements, investigate architecture, generate alternatives, rewrite plans, and recover from incorrect assumptions.
Better intent reduces that uncertainty before expensive implementation begins.
The sequence becomes:
Intent first.
Then repository understanding.
Then planning.
Then implementation.
Then verification.
Instead of paying the model to discover what we meant while it is already writing code, we establish enough intent to constrain the problem first.
From Intent to Evidence
Perhaps the most important part of Intent Kit is what happens at the end.
Intent Kit doesn’t consider:
“Claude says it’s done.”
to be sufficient evidence of completion.
An intent can produce an evidence.md artifact containing actual verification results:
Tests: PASS
Build: PASS
Lint: PASS
Acceptance Criteria:
✓ Customer can view invoices
✓ Newest invoice appears first
✓ Authentication preserved
✓ Tests pass
✓ Build succeeds
DELIVERY STATUS: READY
Evidence should represent actual execution—not simply the agent’s opinion about its own work.
That distinction becomes extremely important as organizations allow AI agents to perform increasingly autonomous development work.
The Bigger Idea: An Operating Layer for AI Engineering
Intent Kit isn’t really about another CLI.
The CLI is intentionally small.
The larger idea is an operating layer.
Business Intent
↓
Intent
↓
Repository Context
↓
Standards + Constraints
↓
Planning
↓
AI Coding Agent
↓
Implementation
↓
Verification
↓
Evidence
↓
Business Impact
Today that coding agent might be Claude Code.
Tomorrow it might be Cursor.
It might be Copilot.
It might be Codex or another agent entirely.
The agent can change.
The intent shouldn’t have to.
That makes Intent the durable asset.
Spec-Driven or Intent-Driven?
The industry doesn’t necessarily need to choose one winner.
Spec-Driven Development is pushing software engineering in an important direction.
Intent-Driven Engineering takes the idea one level higher.
A specification describes what software should do.
Intent asks:
Why are we changing the system, what outcome are we trying to produce, what constraints must remain true, and how will we prove that the outcome was achieved?
From there, specifications, plans, tasks, code, tests, and evidence can all become compiled artifacts of that intent.
That is the experiment behind Intent Kit.
Try Intent Kit
Intent Kit is open source and available on GitHub.
The goal is deliberately simple:
Open your repository.
Initialize Intent Kit:
npx @intent-driven/kit init
Then work with your coding agent:
/intent Add a health-check endpoint returning service name, version, and status.
And allow the operating layer to handle more of the machinery underneath.
Explore the project here:
For comparison, GitHub’s Spec Kit is available here:
Give both a look.
If you want a rich, explicit Spec-Driven Development framework, Spec Kit is an impressive project.
If you like the underlying principles but want to move more of the complexity away from the developer and focus the workflow around intent, repository context, verification, and outcomes, Intent Kit may be worth trying.
Because ultimately the future of AI software engineering isn’t about generating more code.
It’s about turning human intent into reliable outcomes.
Define Intent → Compile Action → Deliver Impact.
For the Wix post, I’d use “Intent Kit: A Simpler Alternative to Spec Kit for AI-Driven Software Development” as the SEO title. The comparison is fair because current Spec Kit explicitly exposes its multi-stage commands and extensive extension/preset/bundle ecosystem, while Intent Kit’s current README deliberately emphasizes a small command surface, repository discovery, verification, and evidence.
Intent Kit on GitHub · GitHub Spec Kit
Comments