PromptEngineering

A request with a prefix is enough. The spec-driven-guide CLI carries the context for you.

Prefix first · The CLI brings the context

6 Steps

The anatomy of a good SPEC.

A SPEC resembles a PRD (Product Requirements Document), the classic artifact of Product Management. A PRD defines what the product must do for the business. The SPEC brings that same rigour into the engineering cycle, so both sides agree before the first line of code.

1

THE WHY

1. Context

A Spec carries the business argument for the work. Define the problem, and why solving it matters now.

2

THE IMPACT

2. Success Metrics

Without a measurable criterion, nobody can say whether the work succeeded. Define the number that answers it.

3

THE WHAT

3. Scope & Scenarios

User stories grounded in Jobs-to-be-Done, the job the user is trying to get done. Cover the real journey: the happy path and the failure case.

4

THE RULES

4. Constraints & Rules

Business rules and technical limits. The boundaries any valid solution has to respect.

5

THE BOUNDARIES

5. Out of Scope

Defining what will NOT be built is as important as defining what will. First defense against scope creep.

6

THE CHECKPOINT

6. Definition of Done

A non-negotiable contract. Done is only true when it's technically correct, functionally tested, and visually complete.

In Practice

A complete specification, filled start to finish.

Prompt Builder

Pick a track and generate your first specification.

Prompt Builder

Step 1/2: Select Project Type

Select Project Type

TracksPick the project type. The track sets the rules your agent follows from the first request.

PromptEngineering

6 Steps

1. Context

2. Success Metrics

3. Scope & Scenarios

4. Constraints & Rules

5. Out of Scope

6. Definition of Done

In Practice

Prompt Builder

Prompt Builder

Select Project Type

Lite mode

New evolution

Legacy modernization