Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/davidbuenov/dbv-specs-ops/llms.txt

Use this file to discover all available pages before exploring further.

Both Cursor and Windsurf can run the full Spec-Driven Development workflow with zero manual setup. Each editor reads its activation file automatically from the project root at session start: Windsurf uses .windsurfrules, and Cursor uses CLAUDE.md (which Cursor also supports natively). Once the file is in place, the AI assistant loads the SDD context before responding to any message — the same project files, the same core rules, the same lifecycle.

​
What the Activation File Does

Regardless of which editor you use, the activation file serves the same purpose: it instructs the AI to read a defined set of project files before proposing any code or plan, and it points to docs/MASTER_PROMPT.md as the single authoritative source for the full SDD workflow. The AI is instructed to read these files at the start of every session:
FilePurpose
project.config.mdProject identity: name, author, license and file header template
docs/MASTER_PROMPT.mdMandatory workflow, rules and boundaries
docs/SPECIFICATIONS.mdCurrent project requirements
docs/ARCHITECTURE.mdStack and technical decisions
docs/DESIGN.mdVisual design system: color tokens, typography, components and philosophy (if it exists)
memory.mdContext and Decisions: Qualitative knowledge (ADRs, lessons learned, active context)
task.mdCurrent state + Context Snapshot
The core rule enforced by both activation files is identical:
Read docs/MASTER_PROMPT.md and follow its workflow strictly. If you detect contradictions between the prompt and project specs, halt and report before proceeding.

​
Editor Setup

Windsurf loads .windsurfrules from the project root automatically. The file contains the full SDD activation instructions, formatted as a numbered list of steps the AI must follow before any interaction.The .windsurfrules file:
# Windsurf Rules — dbv-specs-ops

This project uses **Spec-Driven Development (SDD)**. Apply these rules in all interactions.

## Before proposing any code

1. Read `project.config.md` to get the project name, author, license and file header template
2. Read `docs/SPECIFICATIONS.md` to understand the current requirements
3. Read `docs/ARCHITECTURE.md` to respect the stack and technical decisions
4. Read `docs/DESIGN.md` to respect the visual design system — colors, typography and components *(if it exists)*
5. Read `memory.md` to load the qualitative context and technical decisions
6. Read `task.md` to know the current project state

The full workflow and development rules are in `docs/MASTER_PROMPT.md`.

## ⚠️ Core Rules (Strong Pointer)

**Read `docs/MASTER_PROMPT.md` and follow its workflow strictly. If you detect contradictions
between the prompt and project specs, halt and report before proceeding.**
All initialization logic (Bootstrap), state checking (Specs Check), lifecycle (Workflow)
and coding standards are centrally defined there to avoid cognitive redundancy.

---

> 🛠️ SDD Framework created by **[David Bueno Vallejo](https://github.com/davidbuenov)** — free and open source · [dbv-specs-ops](https://github.com/davidbuenov/dbv-specs-ops)
1

Copy .windsurfrules to the project root

Place .windsurfrules at the root of your project. Windsurf detects this file automatically — no additional configuration is required inside the editor.
2

Ensure all SDD files are present

Confirm that docs/MASTER_PROMPT.md, project.config.md, memory.md, and task.md are all present at the expected paths. Windsurf’s AI will attempt to read each one at session start.
3

Open the project in Windsurf

Open your project folder in Windsurf. The AI assistant reads .windsurfrules and loads the SDD context before your first message.
4

Type /spec to start the workflow

Send /spec in the Windsurf chat. The AI will run the Engineering Interview and produce a specification draft with explicit assumptions for your review.

​
The SDD Workflow Is Identical Across All Platforms

Once the activation file is loaded, the full six-phase SDD lifecycle — /spec → /plan → /build → /test → /code-simplify → /ship — behaves identically in Cursor, Windsurf, Claude Code, Gemini CLI, and Antigravity. The platform determines how the context is loaded; docs/MASTER_PROMPT.md determines what the AI does with it. This means your project files (task.md, memory.md, docs/SPECIFICATIONS.md) remain the shared source of truth across editors. A developer using Windsurf and a developer using Cursor on the same repository will follow the same process and update the same files.
If you work on a project that already has an existing README.md or CHANGELOG.md at the root, consider using the Subfolder Isolation adoption pattern: copy the entire dbv-specs-ops folder into your project as a subdirectory, then place a minimal .windsurfrules or CLAUDE.md at the root pointing to dbv-specs-ops/docs/MASTER_PROMPT.md.

Build docs developers (and LLMs) love

Get started for freeTalk to us