Jig, OpenSpec and Spec Kit

Side by side
	OpenSpec	Spec Kit	Jig
What it is	Spec-driven development for AI coding assistants. A light spec layer agreed before code is written.	A toolkit that gives coding agents structured processes, templates and documented outcomes.	An AI engineering workflow framework for teams: the whole lifecycle from ticket to postmortem, with a gate at every stage.
Unit of work	A change: its own folder with a proposal, spec changes, design and tasks.	A feature: a spec, a technical plan and tasks, under a project constitution.	A piece of work classified by type (bug, feature, improvement, task), which sets the stages it runs and how deep.
Documents	`proposal.md`, spec changes (added, modified, removed), `design.md`, `tasks.md`	Constitution, spec, plan, tasks, checklists	PRD (live page and markdown), spec, plan
Written for	Engineers and their agents	Engineers and their agents	Product, design, engineering and approvers (PRD); engineers (spec); agents (plan)
Product requirements	The proposal says why and what	The spec carries user stories and measurable outcomes	A separate plain-language PRD: phases, an MVP cut line, rules with “you'll know it works when”, no code
Decisions and sign-off	Not built in	Not built in. An optional idea-assessment extension ends in go, clarify or stop.	Open decisions with owners and dates; sign-off per revision on the live page
Status the team can see	Files in the repo	Files in the repo	A live page: milestones, decisions, log and trace, updated by people and by the pipeline
Requirements after ship	Archiving a change merges it into living specs per area. This is OpenSpec's strongest idea.	One spec per feature	The PRD keeps its trace and log. Living per-area specs are on the roadmap.
Ticket trackers	Not built in	Turns tasks into GitHub Issues	Linear, Jira and GitHub Issues packs; Linear can sync documents to a dedicated project
Execution	Apply tasks with your agent	Implement, then converge until done	Picks parallel agent teams or serial execution from the task graph; test-first on every task
Quality gates	Verify (in the expanded command set)	Clarify, analyze, checklists, converge	PRD and spec review swarms, a spec and quality gate per task, specialist code review, PRD check
Pull requests	Not built in	Not built in	Writes the PR and responds to review comments: fix, commit, push, reply, resolve
Learning from mistakes	Not built in	Not built in	Postmortem after merge turns review misses into new specialists and skills
Team customization	Config profiles, community schemas	Constitution, extensions, presets, bundles, organization catalogs	Three layers: team overrides pack overrides core; team specialists are discovered automatically
Across repos	Stores (beta): a planning repo shared across code repos	Organization catalogs of extensions and presets	The PRD lives outside any repo, as a page the whole team opens
Coding agents	30+ tools	38 integrations	Claude Code (plugin); Gemini CLI and Codex adapters
Setup	npm or Homebrew, then `openspec init`	`specify` CLI via uv, then `specify init`	Add the plugin to `.claude/settings.json`, then `/jig:init`
License	MIT	MIT	MIT

Side by side

OpenSpec

Spec Kit

Jig

What it is

Spec-driven development for AI coding assistants. A light spec layer agreed before code is written.

A toolkit that gives coding agents structured processes, templates and documented outcomes.

An AI engineering workflow framework for teams: the whole lifecycle from ticket to postmortem, with a gate at every stage.

Unit of work

A change: its own folder with a proposal, spec changes, design and tasks.

A feature: a spec, a technical plan and tasks, under a project constitution.

A piece of work classified by type (bug, feature, improvement, task), which sets the stages it runs and how deep.

Documents

proposal.md, spec changes (added, modified, removed), design.md, tasks.md

Constitution, spec, plan, tasks, checklists

PRD (live page and markdown), spec, plan

Written for

Engineers and their agents

Product, design, engineering and approvers (PRD); engineers (spec); agents (plan)

Product requirements

The proposal says why and what

The spec carries user stories and measurable outcomes

A separate plain-language PRD: phases, an MVP cut line, rules with “you'll know it works when”, no code

Decisions and sign-off

Not built in

Not built in. An optional idea-assessment extension ends in go, clarify or stop.

Open decisions with owners and dates; sign-off per revision on the live page

Status the team can see

Files in the repo

A live page: milestones, decisions, log and trace, updated by people and by the pipeline

Requirements after ship

Archiving a change merges it into living specs per area. This is OpenSpec's strongest idea.

One spec per feature

The PRD keeps its trace and log. Living per-area specs are on the roadmap.

Ticket trackers

Not built in

Turns tasks into GitHub Issues

Linear, Jira and GitHub Issues packs; Linear can sync documents to a dedicated project

Execution

Apply tasks with your agent

Implement, then converge until done

Picks parallel agent teams or serial execution from the task graph; test-first on every task

Quality gates

Verify (in the expanded command set)

Clarify, analyze, checklists, converge

PRD and spec review swarms, a spec and quality gate per task, specialist code review, PRD check

Pull requests

Not built in

Writes the PR and responds to review comments: fix, commit, push, reply, resolve

Learning from mistakes

Not built in

Postmortem after merge turns review misses into new specialists and skills

Team customization

Config profiles, community schemas

Constitution, extensions, presets, bundles, organization catalogs

Three layers: team overrides pack overrides core; team specialists are discovered automatically

Across repos

Stores (beta): a planning repo shared across code repos

Organization catalogs of extensions and presets

The PRD lives outside any repo, as a page the whole team opens

Coding agents

30+ tools

38 integrations

Claude Code (plugin); Gemini CLI and Codex adapters

Setup

npm or Homebrew, then openspec init

specify CLI via uv, then specify init

Add the plugin to .claude/settings.json, then /jig:init

License

MIT

Which one fits

Choose OpenSpec if you mostly change existing code and want something light. Its change folders are easy to review, and archiving each change into a living spec per area means the specs describe the system as it is now, not as it was planned. That's an idea we plan to borrow.

Choose Spec Kit if you want a thorough, well-documented process that works with whichever coding agent each developer prefers. Its constitution, checklists and cross-artifact analysis catch a lot before implementation starts, and its extensions cover bug fixing and idea assessment.

Choose Jig if you're a team where:

product, design or other stakeholders need to read the requirements and sign off;
work is tracked in Linear, Jira or GitHub Issues;
several agents build in parallel and you want every task checked against the spec;
you want review, pull request responses and a postmortem that improves the next run, in the same pipeline.

Where Jig is behind

Agent support. Jig is built for Claude Code. Gemini CLI and Codex have adapters, but the live PRD page needs Claude. Spec Kit and OpenSpec support far more agents.
Living specs. OpenSpec keeps per-area specs current as changes land. Jig keeps each PRD current while its work moves, but doesn't yet merge shipped specs into a per-area record.
Weight. A full Jig pipeline is more process than a quick fix needs. Work type sets the depth (a bug skips the PRD and gets a lighter review), but OpenSpec is lighter still.
Community. OpenSpec and Spec Kit have tens of thousands of users and many contributors. Jig is newer and smaller.

Checked on October 10, 2026 against each project's own repository and documentation: OpenSpec v1.14.1, Spec Kit v1.1.3 and its docs. Both projects move quickly.

← Read the Jig 2.0 story