How Spektacular Works

A deep dive into spec-driven development — from writing your first spec to shipping working code.

Quick start

Zero to code in under 5 minutes.

1

Install

Requires Go 1.21+ and a supported coding agent CLI (Claude Code, Bob, or Codex) installed and configured.

# install with go
go install github.com/jumppad-labs/spektacular@latest

# or download a pre-built binary from the releases page
# https://github.com/jumppad-labs/spektacular/releases
2

Initialise your project

Run this from the root of your codebase, naming the coding agent you want to use (claude, bob, or codex). Creates a .spektacular/ directory with config, knowledge base, and template files.

cd my-project
spektacular init claude
3

Create a spec

Scaffold a new spec by passing a JSON payload with the feature name. The command returns the normalised spec_name and spec_path — use those for the follow-up steps rather than assuming the filename.

spektacular spec new --data '{"name":"auth-feature"}'
$EDITOR .spektacular/specs/<returned-spec-name>.md
4

Generate a plan

Pass the spec name returned by step 3. The plan workflow explores your codebase, asks clarifying questions, and writes the plan to .spektacular/plans/ when done.

spektacular plan new --data '{"name":"<returned-spec-name>"}'
5

Implement the plan

Pass the plan name returned by step 4. Spektacular drives the coding agent through each phase of the plan and validates the result against your acceptance criteria.

spektacular implement new --data '{"name":"<plan-name>"}'

The spec format

Specs are plain markdown files. No special syntax — just structured sections that give the planning agent what it needs.

# Feature: User Authentication

## Overview
Add OAuth2 login with Google and GitHub
providers to the existing Express app.

## Requirements
- [ ] Users can sign in with Google OAuth2
- [ ] Users can sign in with GitHub OAuth2
- [ ] Session persists across browser refreshes
- [ ] Logout clears session and redirects

## Constraints
- Must use existing Express backend
- No new dependencies over 50KB gzipped
- Cannot change the /api/users schema

## Acceptance Criteria
- [ ] Login redirects to provider, returns
      with valid session
- [ ] Session cookie is httpOnly, secure,
      sameSite=strict
- [ ] Logout flow works end-to-end

## Technical Approach
Use passport.js for OAuth2 strategy.
Integrate with existing session middleware.

## Success Metrics
- OAuth2 login completes in under 2 seconds
- Zero increase in /api/users error rate

## Non-Goals
Social login with Apple or Microsoft.
## Overview

A concise 2–3 sentence summary answering: what is being built, what problem does it solve, and who benefits? Grounds the agent before it reads anything else.

## Requirements

A checklist of discrete behaviours. Use active voice (“Users can…”). Each item should be independently verifiable and focus on what, not how.

## Constraints

Non-negotiable boundaries — existing APIs, dependency limits, performance budgets. Violations are plan failures. Leave blank if none.

## Acceptance Criteria

Binary pass/fail conditions, each traceable to a requirement and testable by someone who didn’t write the code. These become the verification steps in the output plan.

## Technical Approach

High-level technical direction — key architectural decisions, preferred patterns, integration points, and known risks. Leave blank to let the planner propose an approach.

## Success Metrics

How you’ll know it works well after delivery. Quantitative (“p99 latency < 200ms”) or behavioural (“users complete the flow without support”). Leave blank if not applicable.

## Non-Goals

Explicitly out of scope — prevents scope creep and over-engineering. Leave blank if there are no exclusions to call out.

The pipeline

Three stages: write the spec, generate a plan, then implement and validate.

1 Specification

💡
idea
requirements,
constraints & criteria
Write
structured markdown
spec template
📄
spec.md
your requirements
in a standard format

Run spektacular spec new to scaffold a spec from the template, then fill in your requirements, constraints, and acceptance criteria. The spec is plain markdown — no special syntax, just structured sections.

2 Generate the Plan

📄
spec.md
your requirements
Plan
explores codebase,
asks questions
📋
plan.md
+ research.md
+ context.md

Plan turns the spec into a detailed implementation plan. It loads your project knowledge base, explores the codebase, and surfaces clarifying questions before writing anything. The plan, plus supporting research and context documents, are written to .spektacular/plans/.

3 Implement the Plan

📋
plan.md
implementation plan
+ research + context
Implement
executes plan via
coding agent
validates against
acceptance criteria
code
working implementation
verified by criteria

Implement drives the coding agent through each phase of the plan and verifies the output against your acceptance criteria — so you know the implementation matches the spec.

Ready to start?

Install Spektacular and generate your first plan in minutes.

$ brew install jumppad-labs/homebrew-repo/spektacular