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 run.yaml. Engineering specs answer how to build; Lamina answers what the product must allow in each state. Pair them: run /lamina-design first, feed implement.md 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 headless product design skill for AI coding agents. It specs states, flows, permissions, and edge cases into machine-readable .lamina/ contracts, then verifies live builds with /lamina-verify. It is not a UI tool, headless CMS, app builder, or uselamina.ai. Compare Spec tools to Lamina when you need durable behavior contracts in your repo, 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 implement.md into your workflow.

Curated by Aryan Iyappan · Updated 2026-07-13

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 a behavior contract helps.

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	Behavior contract layer (upstream)
Primary output	Tasks, APIs, acceptance criteria	run.yaml + implement.md
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	.lamina/ contracts
Post-build verification	Tests against engineering criteria	Persona walks on live UI
Repo and stack fit	Spec-driven repos	Pairs with any spec tool
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 implement.md 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	Behavior contract upstream
agentic-spec, nib	Component/token enforcement	Product-level flows
OpenSpec-style workflows	Repo spec conventions	run.yaml as behavior input

Frequently asked questions

Which comes first: Lamina or Spec Kit?

Product behavior with /lamina-design first, then engineering tasks from implement.md.

Is implement.md duplicate of my engineering spec?

implement.md 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, repo artifacts, and HavenStay demo examples. Updated when major tools change positioning.

Install in one command.

A headless product-design skill for your AI coding agent. Then run the design → implement → verify loop on your next feature.

Apache-2.0 · open source. Star on GitHub if Lamina saves you a loop.

npx skills install aryaniyaps/lamina

Works with your coding agent

Cursor
Claude Code
Codex
Gemini
Pi
and more