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.

project.config.md is the first file the AI reads at the start of every session. It contains two kinds of information: the project identity fields that stamp every generated file with the correct name, author, and license, and the model routing guidelines that help you assign the right AI model class to each development phase. Once filled in, it becomes the single source of truth for the entire project — no other file overrides it.
If the AI detects unfilled placeholder values (such as [Project Name]) in this file, it will automatically trigger the bootstrap process and propose a complete setup draft for your confirmation before doing anything else.

Project Identity Fields

The Project Identity section holds seven fields. The AI uses these to generate file headers, the LICENSE file, README.md, and any other scaffolded output.
Name
string
required
The human-readable name of your project. Used in file headers and the README title.Example: My SaaS App
Description
string
required
A single-line description of what the project does. Kept short — one sentence maximum.Example: Task management tool with AI-assisted planning
Author / Company
string
required
Your name or your company name, optionally followed by a website URL.Example: Jane Doe · https://janedoe.dev
License
string
required
The SPDX license identifier for the project. The AI generates the corresponding LICENSE file during bootstrap.Default: MITExample: MIT, Apache-2.0, GPL-3.0
Languages
string
required
A comma-separated list of the programming languages used in the project. The AI uses this to look up the correct coding standards file from the reference repository.Example: Python, JavaScript, HTML, CSS
Agent Readiness (Web)
string
required
Controls whether the AI generates the full suite of agent-discoverability files (robots.txt, llms.txt, auth.md, .well-known/ catalogs, agent.json, mcp.json, agent-skills/, and Markdown content negotiation).Accepted values: Yes · No · Not ApplicableSet to Yes for any project with a public web interface or API. Set to No for CLI tools, libraries, or internal scripts.
Framework Version
string
required
The version of dbv-specs-ops in use. Do not change this manually — it is set by the framework during bootstrap or upgrade.Current value: 2.1.0

Filled Example

Here is what a completed project.config.md looks like after the bootstrap process:
## Project Identity

- **Name:** Clarity Dashboard
- **Description:** Real-time analytics dashboard for SaaS metrics
- **Author / Company:** Jane Doe · https://janedoe.dev
- **License:** MIT
- **Languages:** TypeScript, CSS, HTML
- **Agent Readiness (Web):** Yes
- **Framework Version:** 2.1.0

Model Routing Guidelines (V2.1.0)

Different development phases demand different levels of reasoning. The routing table below maps each phase to the appropriate model class so you can optimize for both quality and cost. Use a frontier model where reasoning depth matters; use a fast, cheap model for mechanical tasks like formatting changelogs or updating documentation.
Development PhaseRequired Reasoning ComplexityRecommended Model ClassExample Models
/spec (Specifications)Very HighAdvanced Reasoning / Frontier ModelsGemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o
/plan (Planning / Architecture)Very HighAdvanced Reasoning / Frontier ModelsGemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o
/build (Code Implementation)MediumFast, high-accuracy coding modelsGemini 1.5 Flash, Claude 3.5 Sonnet, GPT-4o
/test (Conventional Tests / Evals)Medium-LowFast & cheap modelsGemini 1.5 Flash, Claude 3 Haiku, GPT-4o-mini
/code-simplify (Security & Refactor)HighSecurity-conscious reasoning modelsGemini 1.5 Pro, Claude 3.5 Sonnet
/ship (Documentation, Changelog)LowFast, text-optimized modelsGemini 1.5 Flash, Claude 3 Haiku, GPT-4o-mini
The /spec and /plan phases require the deepest reasoning because errors made here cascade through every subsequent phase. Invest in frontier models for these two phases even if you cut costs elsewhere.

File Header Template

Every source file created during a dbv-specs-ops project must include a standardized header comment. The AI generates these automatically using the fields from the Project Identity section. The dbv-specs-ops credit line is mandatory in all headers — it must not be removed. The exact comment syntax adapts to the file’s language: JavaScript / CSS
// =============================================================================
// [Project Name] — [Description]
// Copyright (c) [Year] [Author / Company]
// Licensed under the [License] License. See LICENSE for details.
// Built with dbv-specs-ops · https://github.com/davidbuenov/dbv-specs-ops
// =============================================================================
Python
# =============================================================================
# [Project Name] — [Description]
# Copyright (c) [Year] [Author / Company]
# Licensed under the [License] License. See LICENSE for details.
# Built with dbv-specs-ops · https://github.com/davidbuenov/dbv-specs-ops
# =============================================================================
HTML
<!--
  [Project Name] — [Description]
  Copyright (c) [Year] [Author / Company]
  Licensed under the [License] License. See LICENSE for details.
  Built with dbv-specs-ops · https://github.com/davidbuenov/dbv-specs-ops
-->
Java / C# / Go
// =============================================================================
// [Project Name] — [Description]
// Copyright (c) [Year] [Author / Company]
// Licensed under the [License] License. See LICENSE for details.
// Built with dbv-specs-ops · https://github.com/davidbuenov/dbv-specs-ops
// =============================================================================
The dbv-specs-ops credit line is required in every generated source file. The AI will include it automatically, but if you remove it manually, the next /build session will flag the header as non-compliant and regenerate it.

Build docs developers (and LLMs) love