The Human-Speed Steps

In March I wrote that the spec is the product. Precise input, precise output, across as many agents as you care to run. I still believe that. But it left people out.

Jig 1.x had a skill called prd. It wrote API contracts, data models, UI states and an acceptance checklist tagged by layer. Our spec reviewer checked every task against it, and it worked. Then the feedback came in, and it was fair: that “PRD” was a technical spec with a product name on it. Nobody in product, design or support could read it, and nothing in Jig was written for them.

The agents had a contract. The people deciding what to build had nothing.

Jig 2.0 fixes that. This is the story of why, what we built, and how Jig compares to the other spec-driven tools you might be weighing.

Where the handoff breaks

Here's how a feature used to move through our team.

An idea starts in a Slack thread. Someone writes it up in a Google Doc, and comments pile up in the margins. Engineering copies the parts they need into a markdown file in the repo, because that's where the agents can read it. A cleaner version lands in Confluence for the people who weren't in the thread. Sign-off happens back in Slack, as a thumbs-up on a message nobody can find three weeks later.

Now there are four copies of the requirements, and none of them is the source of truth. The Google Doc has the latest decision. The markdown file has what the agents built against. Confluence has what leadership thinks we're building. Slack has the reasoning, buried.

That's the handoff: the moment product intent turns into an engineering contract. It's where things went sideways for us. The code was rarely the problem. A decision that changed in one place and not the others usually was.

Agents make this worse in a specific way. A person reading a stale doc will often notice something is off and ask. An agent reads whatever file it's given and builds it, confidently, five times in parallel.

Why we leaned into Claude

We'd already gone all in on Claude Code for engineering. Skills, subagents, plugins and worktrees gave us the parts to build a real pipeline instead of a pile of prompts, and Jig runs on them.

The missing piece was the rest of the team. Product managers, designers and stakeholders don't live in a terminal, but more and more of them were already working in Claude: drafting docs, thinking through problems, sharing what they made. Claude artifacts gave us what we didn't have: a real web page the whole team can open, that Claude can write to, and that keeps its own shared data.

That last part is what mattered. An artifact can hold records that people change from the page and that Claude Code changes from a session. So the PRD doesn't have to be one more copy. It can be the place.

It also means a product manager can write a PRD without touching the repo. /jig:prd works in Claude.ai and the desktop app as well as Claude Code. Looking at the code is optional, but recommended: it's how the PRD learns what a change really touches.

Build stopped being the slow part

A few weeks before we shipped, Anthropic published The AI-Native SDLC Playbook. One line in it could be the thesis for Jig 2.0:

That matches what we saw. Agents took features from weeks to hours. What stayed slow was human: agreeing on what to build, getting the right people to say yes, and knowing where things actually stand. A faster model doesn't help with any of that. A better loop does.

The playbook's answer is a loop where each stage ends by writing a file the next stage reads, with people approving at defined gates. Jig already had the engineering half of that loop. 2.0 adds the half that starts before the first line of code.

Three documents, three readers

The PRD is for everyone. Plain language, no code. One sentence that says what this is for. The people who feel the problem and the moments they'll see. Rules written as behaviours, each with “you'll know it works when.” Phases with an MVP cut line. Milestones, open decisions with owners and dates, and who signs off. When a rule needs steps, it gets plain-language pseudo steps, never real code.

The spec is for engineers. This is the old prd, renamed and kept in substance: the API, the data, the rules and the UI, with an acceptance checklist tagged by layer. Engineering writes it straight from the PRD link, and every checklist item points back to the PRD outcome it serves.

The plan is for agents. Small, test-first tasks with exact file paths and a dependency graph, so build knows what can run in parallel.

Each one traces to the one before it. A PRD outcome like MVP.2 becomes spec items, spec items become tasks, and every task is checked against the spec. When someone asks why a task exists, the answer is a link.

A PRD that stays current

This is the part I'm most excited about.

A Jig PRD publishes as a live page. It looks like an engineering drawing: a drafting-paper grid, indigo for the work, a pink “markup pen” for what changed and what's still open, dashed lines for things outside our control, and a title block for sign-off at the bottom. (A jig is a manufacturing tool. We leaned in.)

People work on the page directly:

• Tick milestones as they land.
• Choose an option on an open decision, with the reasoning saved next to it.
• Sign off on the current revision. A new revision asks again.
• Leave a note in the log.

And Jig writes to the same page from Claude Code as the work moves:

• spec opens decisions it finds in the code that the PRD didn't settle.
• build ticks milestones as their tasks pass review.
• The PRD check fills in the trace: each promised outcome, and how someone watched it work.
• finish logs the pull request.

So when someone asks “where are we on this?” the answer is a link. Product sees the build move. Engineering gets decisions made without a meeting. Nobody reconciles four copies, because there's one.

Two details I care about. When two people change the same thing at once, the page refuses the second write and asks that person to look again, instead of quietly overwriting. And sign-off is honest about its limits: it records the account that pressed the button, so a wrong sign-off is visible, but today it can't prevent one. That's written down in the release notes, along with everything else we traded off to ship.

A new gate before shipping

The spec reviewer asks: did we build what the spec says? That's necessary, and it isn't enough. You can pass every acceptance criterion and still ship something a person can't use.

So 2.0 adds a PRD check after review. It walks each in-scope outcome from the user's side and asks a different question: can a person now do what the PRD promised? “Verified” means someone, agent or human, watched it work and wrote down how. The proof goes on the page for anyone to judge.

Review also gained four specialists for the PRD itself, reading it the way a non-engineer would: plain-language, mvp-cut, testable-outcomes and missing-moments. Same lesson as March: narrow reviewers beat one reviewer that knows everything.

How Jig maps to the playbook

The playbook lays out six stages. Here's where each one lives in Jig.

We agree on most of it. A few places we differ, and one gap worth naming.

Sign-off stays. The playbook moves work through committed files “rather than tickets and sign-offs.” For a small team, that's right. A growing one has stakeholders who will never review a pull request but still need to say yes. Jig keeps sign-off and makes it live and traceable, instead of a thumbs-up in Slack.

Trackers stay too. The playbook's advice for Jira is to name one source of truth for each artifact, or link the two. Jig's packs for Linear, Jira and GitHub Issues follow that: the ticket tracks the work, the PRD holds what it's for and names its ticket, and the Linear pack can sync documents into a dedicated project.

Learning is built in. The playbook says to treat a repeated mistake as a signal to update CLAUDE.md or add a skill. That's Jig's postmortem, run after every merge.

The gap is production. The playbook's Maintain stage watches production and turns incidents into new work. Jig's loop closes at the postmortem, after the merge; it doesn't watch production yet. Keep your monitoring. And most of Jig's gates are skills, and the playbook is right that “the skill makes violations rare and the hook makes them close to impossible.” If a rule must always hold, back it with a hook.

Jig built Jig 2.0

Jig develops itself with itself, and 2.0 was no exception. It shipped as one pull request of 18 commits: the rename, the page kit, the new pipeline stages, the new specialists and the upgrade path for 1.x teams.

Claude's code reviewer went over it several times. Each round found something real, like a page write that could wipe a note Jig had logged, or a lock that one person's two open tabs would share. We fixed every one. We pushed back once, when it suggested batching page writes, because the page's database can't write several records at once. The page is covered by 29 browser checks that drive it the way a person would, and the 1.x upgrade was run on a real 1.x checkout before we called it done.

Jig, OpenSpec and Spec Kit

If you're looking at spec-driven development, you've probably seen OpenSpec and GitHub's Spec Kit. Both are good, both are open source, and both are far more popular than Jig. They're worth understanding on their own terms, because they answer different questions.

The short version: if you're one developer, or a small team working mostly in one repo, OpenSpec and Spec Kit are both excellent. OpenSpec is light and great for changes to existing code. Spec Kit is thorough and works with almost any coding agent. If you're a team where product signs off, work lives in a tracker, and several agents ship in parallel, that's what Jig is for.

The full comparison →

You scale trust

In March I wrote that you don't scale speed, you scale trust. Back then, trust meant quality gates between agents. In 2.0 it reaches further, to the people who never open a terminal but still decide what gets built and whether it's ready.

One place for the requirements. One place to say yes. A pipeline that writes back to it as the work moves. That's the loop.

Run /jig:init to start. On 1.x already? Run it and choose Upgrade to 2.0.