create-specification

name	create-specification
description	Create a new specification file for the solution, optimized for Generative AI consumption.

Crear especificación

Tu objetivo es crear un nuevo archivo de especificación para ${input:SpecPurpose}.

El archivo de especificación debe definir requisitos, restricciones e interfaces de los componentes de la solución de forma clara, no ambigua y estructurada para un uso eficaz por AIs generativas. Sigue estándares de documentación establecidos y asegura que el contenido sea legible por máquina y autocontenido.

Buenas prácticas para especificaciones preparadas para IA

• Usa lenguaje preciso, explícito y no ambiguo.
• Distingue claramente entre requisitos, restricciones y recomendaciones.
• Usa formato estructurado (encabezados, listas, tablas) para facilitar el parseo.
• Evita modismos, metáforas o referencias dependientes del contexto.
• Define todos los acrónimos y términos específicos del dominio.
• Incluye ejemplos y casos límite cuando aplique.
• Asegura que el documento sea autocontenido y no dependa de contexto externo.

La especificación debe guardarse en el directorio /spec/ y nombrarse según la siguiente convención: spec-[a-z0-9-]+.md, donde el nombre debe describir el contenido y comenzar con el propósito de alto nivel, que debe ser uno de [schema, tool, data, infrastructure, process, architecture, or design].

El archivo de especificación debe estar en Markdown bien formado.

Los archivos de especificación deben seguir la plantilla de abajo, asegurando que todas las secciones estén correctamente completas. El front matter del markdown debe estar estructurado correctamente según el ejemplo siguiente:

---
title: [Concise Title Describing the Specification's Focus]
version: [Optional: e.g., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optional: YYYY-MM-DD]
owner: [Optional: Team/Individual responsible for this spec]
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
---

# Introduction

[A short concise introduction to the specification and the goal it is intended to achieve.]

## 1. Purpose & Scope

[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]

## 2. Definitions

[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]

## 3. Requirements, Constraints & Guidelines

[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]

- **REQ-001**: Requirement 1
- **SEC-001**: Security Requirement 1
- **[3 LETTERS]-001**: Other Requirement 1
- **CON-001**: Constraint 1
- **GUD-001**: Guideline 1
- **PAT-001**: Pattern to follow 1

## 4. Interfaces & Data Contracts

[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]

## 5. Acceptance Criteria

[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]

- **AC-001**: Given [context], When [action], Then [expected outcome]
- **AC-002**: The system shall [specific behavior] when [condition]
- **AC-003**: [Additional acceptance criteria as needed]

## 6. Test Automation Strategy

[Define the testing approach, frameworks, and automation requirements.]

- **Niveles de prueba**: Unit, Integration, de extremo a extremo
- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
- **Test Data Management**: [approach for test data creation and cleanup]
- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
- **Coverage Requirements**: [minimum code coverage thresholds]
- **Performance Testing**: [approach for load and performance testing]

## 7. Rationale & Context

[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]

## 8. Dependencies & External Integrations

[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]

### External Systems
- **EXT-001**: [External system name] - [Purpose and integration type]

### Third-Party Services
- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]

### Infrastructure Dependencies
- **INF-001**: [Infrastructure component] - [Requirements and constraints]

### Data Dependencies
- **DAT-001**: [External data source] - [Format, frequency, and access requirements]

### Technology Platform Dependencies
- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]

### Compliance Dependencies
- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]

**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".

## 9. Examples & Edge Cases

    ```code
    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
    ```

## 10. Validation Criteria

[List the criteria or tests that must be satisfied for compliance with this specification.]

## 11. Related Specifications / Further Reading

[Link to related spec 1]
[Link to relevant external documentation]