jig

jig

A Claude Code plugin that scaffolds AI-native development practices into new projects.

jig (noun): a tool that guides other tools to work accurately and consistently.

Why jig

Two years of AI-assisted coding leave the same scars on every non-trivial project: LLMs refactor whole layers before anything works end-to-end, "done" drifts because no acceptance criteria are written down, implementers grade their own homework, and mega-packs burn the context budget before your work loads. jig encodes the workflow that prevents each one — so you don't rediscover it session by session.

→ The jig philosophy — the full why: the named scars, how jig thinks, and the honest objections.

What it does

jig installs a focused, opinionated workflow layer into your project:

• Spec-driven development — SPIDR-split vertical slices, each with its own Definition of Done.
• Multi-perspective review — a fresh, read-only reviewer checks every slice against its spec (compliance), plus a craft pass and an on-demand architecture pass.
• Memory layer — cross-session continuity via hot cache + deep storage + inbox.
• Deterministic gates — hooks enforce what must happen; skills carry judgment.

A fixed, opinionated set — 7 Tier 0 skills at the floor and 8 more on by default (Tier 1) — not a hundred-skill marketplace. For the full picture, see product-vision.md (vision, target users, principles) and architecture.md (mechanics).

Principles jig encodes

The convictions behind the mechanisms — each one wired into something concrete, not left as advice:

• The harness matters more than the model. jig is a harness: the instructions an agent reads, the tools it can run, the feedback loops that correct it, the isolation boundaries that contain it. Swapping models won't close a workflow gap — the scaffold does.
• Guardrails, not guidelines. What must happen is enforced mechanically by hooks (secret scanning, spec gates, review-evidence gates); what takes judgment lives in skills. The line between a deterministic gate and an advisory nudge is drawn on purpose.
• The context window is working memory, not a storage buffer. Irrelevant context degrades reasoning, so jig keeps a lean hot cache, loads deeper docs on demand, and delegates file-heavy reading to subagents that return only a summary.
• Designed to reduce token cost. Beyond keeping context lean for quality, jig is built to keep token usage — and the bill — down: lean context, file-heavy reading delegated to subagents, tight output. It also measures its own spend rather than guessing at it.
• Review is the bottleneck. Agents produce faster than review capacity grows, so jig won't let implementers grade their own homework: a fresh, read-only reviewer checks every slice against its spec, and the verdicts are durable artifacts that gate the next state.
• Specs and docs are code, and they ship in slices. Specs, ADRs, and the memory layer are version-controlled and reconciled before a slice lands — so "done" never drifts, and work arrives as vertical slices instead of one big-bang mega-commit.

These are the outward-facing worldview; several are also load-bearing build rules jig holds itself to, spec by spec — see product-vision § Design principles for the operational detail.

Two more jig is building toward, honestly not yet landed: one development experience across AI tools (a host-adapter layer beyond Claude Code — spec 033) and coordination across a multi-repo workspace (a federation tier — spec 034). Both are on the roadmap, not shipped today.

Start here

New to jig? Read the adoption & readiness guide first — who jig is for, what your repo needs, and your first 30 minutes.

Then, in a Claude Code session at your project root:

Set up this project for AI-native development.

(or the explicit /jig:scaffold-init). This copies jig's docs, skills, hooks, and settings.json into your repo's .claude/, seeds a worked-example spec, and runs a "scaffold complete and verified" check. Follow it with /jig:vision-elicitation to set the vision every later slice is judged against.

Copy-paste prompts live in the prompt cookbook, in the order you run them: scaffold the repo once, then repeat the idea-to-landed loop for every feature.

Install shapes

Two independent choices: how you acquire the plugin, and where the machinery lives once it's installed. Full detail and how to choose in adoption-readiness § Choosing an install shape.