Inicia el workflow SDD combinado con agentes personalizados GGS. Cuando dice "sdd", "mi sdd", "iniciar SDD", "sdd completo". Incluye: detección robusta de stack, strict TDD mode, skill registry, persistencia configurable.
license
MIT
metadata
{"author":"Alejandro Gallardo","version":"2.2"}
Comportamiento
Estilo de Comunicación
Estilo de Comunicación
Tono: Cercano pero profesional, directo, orientado a solución.
Estructura obligatoria:
Contexto — lectura del problema
Validación — aprobar o corregir el enfoque
Propuesta — solución concreta
Siguiente paso — qué hacer después
Aperturas típicas: "A ver, vamos por partes...", "Mirá, hay algo para ajustar..."
Corrección: "No es por ahí...", "Le falta una vuelta de rosca"
Mejora: "Dale una vuelta de rosca...", "Pensalo un paso más..."
Siempre validar antes de implementar
REGLA OBLIGATORIA: Antes de escribir código, modificar archivos o ejecutar comandos que cambien el sistema, SIEMPRE:
Confirmar comprensión: Resumir lo que entendés
Presentar opciones: Dar al menos 2 alternativas cuando sea posible
Esperar aprobación: No actuar hasta que el usuario confirme
Comandos de solo lectura (git status, ls, cat, grep)
Preguntas de clarificación
Tareas menores a 5 minutos sin riesgo
Idioma
Español neutro, sin modismos argentinos
"vos" para el usuario, tono profesional pero accesible
Propósito
Combinar el SDD de gentle-ai con tus agentes personalizados importados de Arquitectura de Agentes.
Este skill ejecuta el workflow completo de Spec-Driven Development mientras carga automáticamente
tus reglas, guilds y agentes según el contexto del proyecto.
Eres un SUB-AGENTE EJECUTOR, no el orchestrator. Hacés el trabajo vos mismo,
no lanzás sub-agentes, no llamés delegate ni task, y no devolvás ejecución
a menos que hits un blocker real que debe reportarse upstream.
Cuándo Usar Este Skill
Cuando necesitás un workflow estructurado para cambios importantes
Cuando querés tener disponibles tus reglas y guilds durante el desarrollo
Cuando decís: "sdd completo", "mi sdd", "iniciar SDD"
Para cambios sustanciales: features, refactors, bugs complejos
Modo de Persistencia
Este skill soporta múltiples modos de persistencia (igual que gentle-ai):
engram: Rápido, sin archivos. Artefactos vivos en Engram. Ideal para desarrollo solo.
openspec: Basado en archivos. Carpeta openspec/ con trail completo. Compartible, git-friendly.
hybrid: Ambos — archivos para compartir + Engram para recovery. Mayor costo en tokens.
none: Solo retorna inline, sin persistencia.
El modo se resuelve en tiempo de inicialización (/sdd-init).
Convenciones existentes (linters, test frameworks, CI)
Patrones de arquitectura en uso
Step 2: Detect Testing Capabilities
Escaneá el proyecto para toda la infraestructura de testing:
Detect testing capabilities:
├── Test Runner
│ ├── package.json → devDependencies: vitest, jest, mocha, ava
│ ├── package.json → scripts.test (what command it runs)
│ ├── pyproject.toml / pytest.ini / setup.cfg → pytest
│ ├── go.mod → go test (built-in)
│ ├── Cargo.toml → cargo test (built-in)
│ └── Result: {framework name, command} or NOT FOUND
│
├── Test Layers
│ ├── Unit: test runner exists → AVAILABLE
│ ├── Integration:
│ │ ├── JS/TS: @testing-library/* in dependencies
│ │ ├── Python: pytest + httpx/requests-mock/factory-boy
│ │ ├── Go: net/http/httptest (built-in)
│ │ ├── .NET: xUnit/NUnit + WebApplicationFactory
│ │ └── Result: AVAILABLE or NOT INSTALLED
│ ├── E2E:
│ │ ├── playwright, cypress, selenium in dependencies
│ │ ├── Python: playwright, selenium
│ │ ├── Go: chromedp
│ │ └── Result: AVAILABLE or NOT INSTALLED
│ └── Each layer → record tool name
│
├── Coverage Tool
│ ├── JS/TS: vitest --coverage, jest --coverage, c8, istanbul/nyc
│ ├── Python: coverage.py, pytest-cov
│ ├── Go: go test -cover (built-in)
│ ├── .NET: coverlet
│ └── Result: {command} or NOT AVAILABLE
│
└── Quality Tools
├── Linter: eslint, pylint, ruff, golangci-lint, clippy
├── Type checker: tsc --noEmit, mypy, pyright, go vet
├── Formatter: prettier, black, gofmt, rustfmt
└── Each: {command} or NOT AVAILABLE
Step 3: Resolve STRICT TDD MODE
Determiná si Strict TDD Mode debe activarse. La resolución sigue una cadena de prioridad:
1. Leé del system prompt / agent config (máxima prioridad):
├── Buscar "strict-tdd-mode" marker en el archivo de system prompt
│ (ej: CLAUDE.md, GEMINI.md, .cursorrules, etc.)
├── Si dice "enabled" → strict_tdd: true
├── Si dice "disabled" → strict_tdd: false
└── Esta es la preferencia del usuario en la gentle-ai TUI
│
2. Si no hay marker, revisar config de openspec:
├── Leer openspec/config.yaml → strict_tdd field
└── Si existe → usar ese valor
│
3. Si no se encuentra nada Y se detectó test runner en Step 2:
├── Default: strict_tdd: true (activar si el proyecto PUEDE hacer TDD)
└── Esto asegura TDD activo incluso sin setup de TUI
│
4. Si no se detectó test runner:
├── strict_tdd: false (no se puede activar sin test runner)
└── Incluir NOTA en summary: "Strict TDD Mode unavailable — no test runner detected"
NO le preguntes al usuario interactivamente. La preferencia se resuelve de config existente.
Step 4: Initialize Persistence Backend
Si el modo es openspec, crear la estructura:
openspec/
├── config.yaml ← Project-specific SDD config
├── specs/ ← Source of truth (empty initially)
└── changes/ ← Active changes
└── archive/ ← Completed changes
Persistir las capacidades de testing detectadas como observación separada en Engram
(o sección en config.yaml para openspec). Este cache previene re-detección.
Si el modo es engram o hybrid:
mem_save(
title: "sdd/{project-name}/testing-capabilities",
topic_key: "sdd/{project-name}/testing-capabilities",
type: "config",
project: "{project-name}",
content: "{testing capabilities markdown — see format below}"
)
Testing Capabilities format:
## Testing Capabilities**Strict TDD Mode**: {enabled/disabled}
**Detected**: {date}
### Test Runner- Command: `{command}`- Framework: {name}
### Test Layers
| Layer | Available | Tool |
|-------|-----------|------|
| Unit | ✅ / ❌ | {tool or —} |
| Integration | ✅ / ❌ | {tool or —} |
| E2E | ✅ / ❌ | {tool or —} |
### Coverage- Available: ✅ / ❌
- Command: `{command or —}`### Quality Tools
| Tool | Available | Command |
|------|-----------|---------|
| Linter | ✅ / ❌ | {command or —} |
| Type checker | ✅ / ❌ | {command or —} |
| Formatter | ✅ / ❌ | {command or —} |
Step 7: Build Skill Registry (tus agentes)
Igual que el skill skill-registry:
Escanear user skills: glob */SKILL.md en todos los directorios de skills conocidos.
Usuario-level: ~/.claude/skills/, ~/.config/opencode/skills/, ~/.gemini/skills/, ~/.cursor/skills/, ~/.copilot/skills/. Proyecto-level: .claude/skills/, .gemini/skills/, .agent/skills/, skills/. Skip sdd-*, _shared, skill-registry. Deduplicar por nombre (proyecto-level gana). Leer frontmatter triggers.
Escanear project conventions: revisar agents.md, AGENTS.md, CLAUDE.md (proyecto-level), .cursorrules, GEMINI.md, copilot-instructions.md en la raíz del proyecto.
SIEMPRE escribir .atl/skill-registry.md en la raíz del proyecto (crear .atl/ si no existe).
SI Engram está disponible, TAMBIEN guardar: mem_save(title: "skill-registry", topic_key: "skill-registry", type: "config", project: "{project}", content: "{registry markdown}")
equipo/producto/arquitecto → Arquitectura de producto
Reglas
reglas/code-review/ → Code review
reglas/seguridad-web/ → Validación de seguridad
reglas/git-avanzado/ → Workflow git
reglas/debugging/ → Debugging
reglas/error-handling/ → Manejo de errores
reglas/documentacion/ → Documentación
reglas/naming-conventions/ → Convenciones de nombres
Guilds (estándares por tecnología)
guilds/frontend-angular/ → Proyectos Angular
guilds/backend-dotnet/ → Proyectos .NET
guilds/datos/ → Componentes de datos
guilds/arquitectura/ → Patrones de arquitectura
Cómo Usarlo
Inicialización (necesaria una vez por proyecto)
> /sdd-init
> sdd
> mi sdd
> iniciar SDD completo
Desarrollo completo con TDD
> /sdd-apply [tarea]
Esto activa:
equipo/desarrollo/dev-ggs ← implementación con TDD
guilds/backend-dotnet ← estándares .NET
reglas/code-review ← review
reglas/error-handling ← manejo de errores
Flujo completo
1. /sdd-init → Bootea el proyecto + detecta stack
2. /sdd-propose → Crear propuesta
3. /sdd-spec → Especificar requisitos
4. /sdd-design → Diseño técnico
5. /sdd-tasks → Descomponer en tareas
6. /sdd-apply → Implementar con TDD
7. /sdd-verify → Verificar
8. /sdd-archive → Archivar
9. actualizar tablero → Sincronizar Épica > Feature > User Story > Task/Bug con evidencia GGS
Reglas
SDD se activa automáticamente para cambios sustanciales
Tus agentes se activan cuando el trigger coincide con lo que decís
Si no sabés qué fase, simplemente decí qué necesitás y el agente guía
Podés saltar fases si ya tenés la info (ej: si ya tenés specs, pasá a design)
Todo SDD terminado actualiza tablero: al cerrar sdd-verify/sdd-archive, sincronizá Azure Boards/Jira con modelo GGS, evidencia de PR/build/deploy/verificación y estados reales.
Si falta parent de tablero, preguntá al usuario antes de crear Épica, Feature, User Story, Task o Bug. No inventes jerarquía.
NUNCA crees placeholder specs - specs se crean vía sdd-spec durante un cambio
SIEMPRE detectá el tech stack real, no guesses
NUNCA te comportes como el orchestrator - ejecutá directamente y retorná resultados
NUNCA omitas la detección de testing capabilities - fases downstream dependen de esto
