Skip to main content
A specification is the structured blueprint that guides pre.dev’s build agents. It’s generated by pre.dev’s planning engine based on your project description, and it contains everything agents need to implement your project correctly.
The Spec view: your full specification, editable and exportable

The Spec view: your full specification, editable and exportable

​
Spec Structure

Every specification follows a hierarchical structure:

​
Components

​
Technical Architecture

The top-level section defines the system design:
  • Tech stack — Languages, frameworks, databases, hosting
  • System design — Component hierarchy, data flows, API contracts
  • Database schema — Tables/collections, relationships, indexes
  • Infrastructure — Deployment targets, CI/CD, environment config

​
Milestones

Milestones are phases of delivery. They’re sequenced so that foundational work comes first:
  • Each milestone has a complexity estimate
  • Milestones are typically built in order (dependencies respected)
  • Example: “Core Foundation” → “User Features” → “Admin & Analytics” → “Polish & Deploy”

​
User Stories

Each milestone contains user stories — feature-level requirements:
  • Written in standard format: “As a [user], I want [feature], so that [benefit]”
  • Include acceptance criteria — specific conditions that must be true for the story to be complete
  • Acceptance criteria become the verification checks during building

​
Subtasks (Deep Spec only)

Subtasks are the granular implementation steps within each story:
  • Specific enough for an agent to implement directly
  • Include task-level complexity estimates
  • Have their own status tracking

​
Task Status Tracking

Every subtask has a status indicator:
These statuses update in real-time as agents work through the spec.

​
Editing Specs

Specifications are living documents. Before or during building, you can:
Add new features you want included, or remove features you’ve decided against. The spec updates immediately.
Change what “done” means for any story. Agents building that task will use the updated criteria.
Adjust delivery priority. Move critical features earlier or defer nice-to-haves.
Switch frameworks, databases, or tools. Subsequent tasks will use the new stack.
Edits are reflected immediately — agents building subsequent tasks will always use the latest version of the spec.

​
How Agents Use Specs

When a build agent picks up a task, it receives:
  1. The full specification for architectural context
  2. The specific subtask it’s responsible for
  3. The acceptance criteria it must satisfy
  4. The current codebase state
  5. Any Integrations entries (API keys, docs)
This focused context means agents don’t hallucinate features or make uninformed architectural decisions — they implement exactly what the spec defines.

​
Example Spec Fragment

​
What’s next?

Fast vs Deep Specs

Pick the right depth for your project.

Build Modes & Effort

Start building against the spec.
The interactive architecture graph, generated with your spec

The interactive architecture graph, generated with your spec