chaidocs
Spec Driven Development for AI Apps

Hands-on: Prompt vs Spec

Anirudh Jwala 8 pages 1 min read Updated Oct 21, 2026
On this page
  1. Prompt vs **Spec**
  2. Reliable bookings, plus **cancellation**
  3. Two users. **One seat**. Both bookings succeed.
  4. What is **OpenSpec**?
  5. The OpenSpec **workflow**
  6. Investigate first, then **plan** the change
  7. Rules we **agree** on before code
  8. Pin down the **behavior**, let tests judge

Prompt vs Spec

Same feature. Two workflows. One set of acceptance tests.

chaicode.com

Problem statement

Reliable bookings, plus cancellation

  1. 01No overbookingNo event is ever booked past capacity
  2. 02One per studentOne booking per student per event
  3. 03Cancel freesCancelling gives the seat back
chaicode.com

The race condition

Two users. One seat. Both bookings succeed.

Disabling the button in React is UX, not enforcement.

chaicode.com

Round 2 tooling

What is OpenSpec?

An open-source, lightweight SDD workflow for the coding agent you already use.

  1. 01Not a frameworkNot a framework, language, or agent
  2. 02Lives in your repoAdds slash commands and a folder of Markdown specs
  3. 03For existing appsBuilt for changing existing apps, one change at a time
chaicode.com

Round 2

The OpenSpec workflow

Explore/opsx:explorePropose/opsx:proposeHuman reviewread and correctApply/opsx:applyVerifysame acceptance testsArchive/opsx:archive123456gaps
  1. 1Explore: inspect the current flow
  2. 2Propose: draft proposal, specs, design, tasks
  3. 3Human review before any code
  4. 4Apply: the agent works the task list
  5. 5Verify, then archive into living specs
  6. 6Gaps found? Revisit the relevant step
chaicode.com

Explore and propose

Investigate first, then plan the change

Explore — no code

/opsx-explore
# Inspect the existing booking flow. We want reliable
# bookings with duplicate prevention, capacity limits,
# cancellation, and concurrency safety. List missing
# rules and options. Do not implement anything.

Propose — one named change

/opsx-propose reliable-event-bookings

openspec/changes/reliable-event-bookings/
├── proposal.md   # why and scope
├── specs/        # requirements and scenarios
├── design.md     # technical approach
└── tasks.md      # implementation checklist
chaicode.com

Review the spec

Rules we agree on before code

  • Signed-in only Anonymous users cannot book
  • One active booking Per student, per event
  • Never over capacity Even with concurrent requests
  • Cancel only your own No cancelling another student's booking
  • Cancel frees the seat The seat returns to the pool
  • Cancelled events reject No bookings on a cancelled event
chaicode.com

Takeaway

Pin down the behavior, let tests judge

A spec defines expected behavior. Independent tests help us verify what actually got built.

chaicode.com