Ambystech · Open source

Spec-Driven Development that specs your UI too.

SpeakerGustavo BarrientosLength~10 minDocsambykit.ambystech.io

~/my-project

$npx @ambystech/ambykit init

? Which assistants do you use? Claude Code, Cursor, Copilot

✓ .amby/ neutral source

✓ .claude/commands/amby/ 10 commands

✓ .cursor/commands/ 10 commands

✓ .github/prompts/ 10 prompts

✓ CLAUDE.md · AGENTS.md merged, backed up

Next: open your assistant and run /amby.constitution

01The problem

The assistant builds the UI it guessed.

Today

A prompt goes straight from idea to code
Requirements live in chat history, not in the repo
The interface is whatever the model imagined
Every assistant wants its own commands, rules and file layout

What we want

Testable requirements before the first line of code
The UI described and signed off, like any other spec
One workflow that runs the same in every tool
A loop that checks the code against the spec

Most SDD frameworks go from user stories straight to a technical plan and leave the interface to the model's imagination.

02What it is

Author your specs once. Emit them for every assistant.

A rigorous, tech-agnostic Spec-Driven Development workflow, with a first-class UI design phase, compiled into the native commands and rules of each AI coding assistant your team uses.

TypeScriptnpm · Node ≥ 20MITEARS requirementsDesign tokensGit worktrees

11phases6assistant families10emit targets1source of truth

03Quick start

From zero to a spec in four commands

~/my-project

$npx @ambystech/ambykit init

✓ scaffolded .amby/ · emitted 3 assistants · CLAUDE.md preserved and backed up

/amby.constitution

Once. The project's guiding principles.

/amby.specify

Describe a feature. Get user stories and EARS requirements.

/amby.design

UI spec plus a real design-tokens file.

/amby.implement

Build it from an ordered, dependency-aware task list.

init is non-destructive: an existing CLAUDE.md or AGENTS.md is preserved and backed up. AmbyKit only owns its own section.

04The workflow

Eleven phases. Each one writes a single artifact.

/amby.constitutionGovernance, once
→ .amby/constitution.md

/amby.specifyWHAT and WHY, no tech
→ spec.md

/amby.clarifyResolves open markers
→ spec.md

/amby.designThe interface, signed off
→ ui.md + design-tokens.json

/amby.planHOW: stack and architecture
→ plan.md

/amby.tasksOrdered, dependency-aware
→ tasks.md

/amby.implementOne slice at a time
→ code

/amby.convergeCode vs spec, gaps appended
→ tasks.md

Plus /amby.revise to continue a spec in place, /amby.analyze to cross-check artifacts, and /amby.review for a different role to critique any of them.

05The design phase

The part every other spec framework skips

specs/001-search/ui.mdauthored

SearchFieldidle · focused · error
ResultCarddefault · selected
PrimaryButtonenabled · loading · disabled

specs/001-search/design-tokens.jsonauthored

primitive"color.brand.500":"#EE1199"

semantic"color.action.primary":"{color.brand.500}"

component"button.primary.bg":"{color.action.primary}"

sign-off makes this binding for plan, tasks and implement

Your assistant builds the interface you described, not the one it guessed.

06Author once, emit per tool

One source. Native files for every assistant.

Rules files are merged, not overwritten. A new target is a thin BaseEmitter subclass.

07A task line

Every line in tasks.md is machine-readable

- [ ] T014 [P] [US2] Add token validation middleware in src/auth/guard.ts

- [ ]checkbox is the status T014stable id, never renumbered [P]safe to run in parallel [US2]story it serves Add token validation middleware in src/auth/guard.tswhat, and the file path

~/my-project

$ambykit dashboard 001:US-2

US-2 Validate tokens P1 in-progress depends-on US-1 ✓

T012 ✓ T013 ✓ T014 · T015 · 2 / 4 tasks · 1 unblocked

Stories carry priority and depends-on / blocked-by. Tasks are ordered topologically, foundational work first.

08Parallel work

Several features, several assistants, no checkout switching

worktreespecifydesignplantasksimplementconvergestatus

.worktrees/auth/Claude Code

runningconverged

.worktrees/billing/Cursor

runningconverged

/amby.review --as qa

A different role critiques any artifact. Findings by stable ID, with severity and a fix. Nothing changes unless you pass --apply.

/amby.converge

Checks the code against every FR, SC and checked task. Appends one gap task per miss. Loop with implement until it says converged.

09The landscape

Why not just Spec-Kit?

	Spec-Kit	Kiro	AmbyKit
EARS requirements	✓	✓	✓
Code-vs-spec drift check	✓	—	✓
Brownfield: revise in place	✓	✓	✓
UI design phase + tokens	—	~ architecture only	✓
Native git worktree isolation	—	—	✓
Cross-role review, patch in place	~ setup bundles	—	✓
Runtime	Python 3.11 + uv	proprietary IDE	Node ≥ 20, npx
Assistants supported	✓ 37 integrations	self-contained	— 6 families, 10 targets

✓ yes · ~ partial · — no

10Recap

What to take away

WHAT before HOW. The spec has no tech decisions; the plan is where tech first appears.

Run npx @ambystech/ambykit init on a project you already have. It won't touch your files.

The UI is a first-class artifact: ui.md plus design-tokens.json, signed off before planning.

Write one spec with /amby.specify, then /amby.design it before you plan.

One neutral source emits native commands and rules for six assistant families.

Loop /amby.implement and /amby.converge until it says converged.

Thank you

Spec the UI too.

Author once. Emit per tool. Ship better software with AI coding assistants.

Docsambykit.ambystech.ioSourcegithub.com/ambystechcom/AmbyKitLicenseMIT