OpenSpec from Scratch
A Spanish-language guide to spec-driven development with OpenSpec: agree on what you are building before you ask your AI agent to build it. First change in 30 minutes, CLI reference, team adoption guide and a PDF manual.
Problem
Asking an AI agent to implement something without first agreeing on what to build produces code that has to be redone: implicit requirements, scope that grows mid-conversation and no record of why the system behaves the way it does. OpenSpec addresses this, but its documentation is in English and assumes familiarity with spec-driven development.
Solution
A guide in Spanish that starts from zero: what OpenSpec is in three sentences, the four-step workflow (explore, propose, apply and archive), a guided first change on a real booking example with Claude Code, the CLI command reference and a guide to adopting it as a team alongside Jira or Azure DevOps. Everything is also downloadable as a PDF manual.
Results
30 min
First change
4
Workflow steps
3
Reading paths
OpenSpec from Scratch is a practical guide to spec-driven development for people who already code with AI agents and want to stop improvising. The core idea is simple: agree in writing on what will be built before asking the agent to build it.
The workflow
The guide is organised around four steps:
- Explore the change and its context.
- Propose the specification (
/opsx:propose): requirements, scenarios and tasks. - Apply the implementation with the agent (
/opsx:apply) against that specification. - Archive the change (
/opsx:archive), so the spec becomes living documentation.
Three reading paths
- Get started: what OpenSpec is and a complete first change in about 30 minutes, using a booking system example.
- Reference: the CLI commands, from
openspec initonwards. - Team: how to adopt it in a team that already works with Jira or Azure DevOps.
The full content can also be downloaded as a PDF manual. The guide itself is written in Spanish.
Gallery
What I learned
- → Specify before generating: a reviewable proposal cuts agent iterations more than any long prompt.
- → Archived specs work as living documentation: the reason behind each change stays next to the code.
- → Adopting SDD in a team means fitting it into the existing workflow (Jira, Azure DevOps), not replacing it.
- → Teaching from scratch forces you to separate the concept from the tool: first the workflow, then the commands.
Architecture · technical leadership · .NET
Hiring a .NET Software Architect or Tech Lead?
Open to full-time employment in software architecture or technical leadership on .NET products. Tell me about the role and the team: I reply within 24–48 h.