Lamina vs spec tools (https://lamina.dev/learn/compare/lamina-vs-spec-tools): Spec tools like GitHub Spec Kit, Kiro, and OpenSpec-style workflows structure engineering implementation: tasks, APIs, file changes, and acceptance criteria for developers and agents. Lamina structures product behavior before that layer: domain state machines, actor permissions, UI flow recovery, and multi-role gates in GraphVersion. Engineering specs answer how to build; Lamina answers what the product must allow in each state. Pair them: run /lamina-design first, feed GraphVersion projection into Spec Kit or Kiro for task breakdown, implement, then /lamina-verify before you lock Playwright scenarios. Skip Lamina for backend-only changes with no UI behavior surface. Lamina (lamina.dev) is an open-source transactional product graph and agent workflow. Its CLI and portable skills publish validated GraphVersions, produce query projections, and verify live builds with independent Persona Missions and runtime evidence. It is not a UI tool, headless CMS, app builder, or uselamina.ai. Compare Spec tools to Lamina when you need durable product knowledge in a local graph, not just generated UI or ephemeral planning. Full guide: https://lamina.dev/learn/compare/lamina-vs-spec-tools.

Lamina vs spec tools

Spec Kit, Kiro, and similar tools structure engineering tasks and acceptance criteria. Lamina specs product-level states, roles, and flows, then feeds GraphVersion projection into your workflow.

Curated by Aryan Iyappan · Updated 2026-07-27

You are in the right place if

Your spec has API tasks but permission matrices are missing.
Engineering specs pass but product behavior still breaks in the UI.
Spec Kit generated tasks from a one-line feature request with no product design.
Kiro workflow is green but guest and partner flows were never distinguished.

Context

Spec-driven development improved how agents break work into PR-sized chunks. The engineering spec layer assumes product behavior is already understood. In AI-assisted builds, that assumption fails often: tasks are well-formed while flows are wrong. Lamina sits upstream of engineering specs, not instead of them.

Common situations

Concrete cases from AI-shipping workflows. Each shows what the alternative handles and where validated graph knowledge and verification evidence help.

Spec Kit tasks for booking API

Situation: Spec Kit produced CRUD tasks and OpenAPI shapes. UI let guests pay while hold was expired because no task covered transition rules.
What Spec tools does: Breaks engineering work into implementable units with acceptance criteria.
What Lamina adds: Product-level state machine and pay preconditions before tasks are generated.
Takeaway: Engineering tasks need a behavior source document.

Kiro structured sprint on auth refactor

Situation: Backend auth migration, no new UI flows or role changes.
What Spec tools does: Kiro workflow coordinates implementation.
What Lamina adds: Skip Lamina unless UI permissions change.
Takeaway: Backend-only: spec tools alone may suffice.

OpenSpec enforces component tokens

Situation: Agentic spec tooling keeps components on design tokens. Partner submit gate still missing.
What Spec tools does: Component and token enforcement during build.
What Lamina adds: Domain permissions and verify on live partner flow.
Takeaway: Token enforcement is not product behavior design.

Comparison

Lamina vs spec tools (Spec Kit, Kiro)
Dimension	Spec tools	Lamina
Primary job	Engineering task structure and SDLC	Product behavior design
Layer in stack	Engineering spec / implementation layer	Transactional product graph + agent workflow
Primary output	Tasks, APIs, acceptance criteria	Validated GraphVersion plus query projections
Writes app source?	Agent implements from engineering spec	No
Behavior spec (states, flows, permissions)	Task-level criteria and API contracts	State machines, actor permissions
Durable in-repo artifact	Spec files in repo	Validated GraphVersion plus query projections
Post-build verification	Tests against engineering criteria	Independent Persona Missions with runtime evidence
Repo and stack fit	Spec-driven repos	CLI plus portable skills in any repo and stack
Best when	Breaking work into engineering tasks	Defining product rules before tasks
When you don't need Lamina	Backend-only change	No UI behavior to spec
Compose with Lamina?	Implement from engineering spec	/lamina-design → feed GraphVersion projection to Spec Kit

Spec tool roster

Lamina vs spec tools: when to use each
Situation	Spec tools	Lamina
Spec Kit	Engineering specs and agent tasks	Product behavior first
Kiro	Structured dev workflow	resolved graph knowledge upstream
agentic-spec, nib	Component/token enforcement	Product-level flows
OpenSpec-style workflows	Repo spec conventions	GraphVersion as behavior input

Frequently asked questions

Which comes first: Lamina or Spec Kit?

Product behavior with /lamina-design first, then engineering tasks from GraphVersion projection.

Is GraphVersion projection duplicate of my engineering spec?

GraphVersion projection is product behavior handoff, not file-level tasks. Spec tools translate it into engineering work.

Spec tools generate tests. Does that replace verify?

Tests assert scenarios you defined. /lamina-verify discovers gaps before tests exist.

Comparisons map stack layers, durable outputs, and provenance-marked legacy examples. Updated when major tools change positioning.

Install Lamina with your agent.

Copy the repository-matched prompt. Your agent installs the standalone CLI, adds every Lamina skill for your active agent, configures supported passive rules, checks the setup, and tells you when to start a fresh session with /lamina-init.

Skills work across coding agents. Passive setup currently supports Codex, Claude Code, and Cursor.