zugzbot-sdd 1.5.18 → 1.5.20

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,23 @@
1
+ # Skill: SDD Auto Rollback Recovery
2
+
3
+ Enseña a los agentes (principalmente `@sdd-deployer`) cómo actuar quirúrgicamente ante un fallo en la fase de despliegue para restaurar la estabilidad de forma atómica.
4
+
5
+ ## Trigger
6
+
7
+ - Falla del comando de despliegue en Fase 4.
8
+ - Respuestas HTTP 5xx o fallos graves en pruebas de salud inmediatamente después del despliegue.
9
+
10
+ ## Procedimiento de Recuperación
11
+
12
+ 1. **Rollback en Control de Versiones**:
13
+ - Identificar el último commit estable.
14
+ - Ejecutar: `git revert HEAD --no-edit` o `git checkout [stable-hash]` de forma controlada.
15
+ 2. **Restauración en Producción**:
16
+ - Re-desplegar la versión estable recuperada.
17
+ 3. **Aislamiento del Error**:
18
+ - Escribir un archivo temporal de error en `.openspec/crash_report.md`.
19
+ - Transicionar de regreso a Fase 2 (`sdd-builder`) para corrección del bug.
20
+
21
+ ## Tags
22
+
23
+ #rollback #deploy #git #recovery #stability
@@ -0,0 +1,22 @@
1
+ # Skill: SDD Brain Curator
2
+
3
+ Instruye al `@sdd-archiver` sobre cómo sintetizar y empaquetar aprendizajes en el archivo de memoria `brain.md`, evitando duplicación de contexto y optimizando la comprensión de la IA en futuras iteraciones.
4
+
5
+ ## Trigger
6
+
7
+ - Fase de cierre (Fase 5) antes de archivar de forma atómica.
8
+
9
+ ## Directrices de Curación
10
+
11
+ 1. **Evitar Duplicidad**:
12
+ - Agrupar lecciones similares en un único bullet.
13
+ 2. **Categorización Estricta**:
14
+ - `[Sintaxis/Tipado]`: Errores relacionados con TypeScript, JavaScript o Apps Script.
15
+ - `[Arquitectura]`: Desacoplamiento de componentes.
16
+ - `[Lógica de Negocio]`: Flujos de negocio e interfaces.
17
+ 3. **Formato ultra compacto**:
18
+ - Escribir oraciones de máximo 20 palabras por aprendizaje.
19
+
20
+ ## Tags
21
+
22
+ #brain #lessons #synthesis #memory
@@ -0,0 +1,20 @@
1
+ # Skill: SDD Clean Architecture
2
+
3
+ Instruye al `@sdd-builder` en principios de desacoplamiento modular para evitar la creación de archivos gigantescos que saturen el contexto de edición.
4
+
5
+ ## Trigger
6
+
7
+ - Fase de codificación (Fase 2).
8
+
9
+ ## Directrices de Diseño
10
+
11
+ 1. **Separación de Capas**:
12
+ - UI / Vista desacoplada de la lógica de servicios y APIs.
13
+ 2. **Componentes Puros**:
14
+ - Funciones pequeñas con una única responsabilidad.
15
+ 3. **Tamaño Límite**:
16
+ - Evitar archivos de código fuente de más de 300 líneas. Si exceden, modularizar de inmediato.
17
+
18
+ ## Tags
19
+
20
+ #architecture #modular #clean-code #builder
@@ -0,0 +1,20 @@
1
+ # Skill: SDD Token Economy
2
+
3
+ Enseña a todos los agentes a operar bajo estrictas directrices de ahorro de tokens y optimización contextual para reducir costos y acelerar la velocidad del swarm.
4
+
5
+ ## Trigger
6
+
7
+ - Cualquier operación del ciclo SDD (constante).
8
+
9
+ ## Directrices Operativas
10
+
11
+ 1. **Lecturas Selectivas**:
12
+ - Usar herramientas de visualización de rangos específicos de líneas en vez de leer archivos enteros.
13
+ 2. **Poda de Logs**:
14
+ - Resumir o eliminar logs repetitivos y trazas gigantescas de la consola.
15
+ 3. **Peticiones LSP de Alto Impacto**:
16
+ - Apuntar la navegación a los símbolos/métodos relevantes de la clase específica en vez de recorrer múltiples módulos.
17
+
18
+ ## Tags
19
+
20
+ #tokens #economy #cost #efficiency
@@ -366,7 +366,7 @@ export default tool({
366
366
  }
367
367
  // 2. Hacer commit automático de los artefactos .openspec/
368
368
  execSync("git add .openspec/", { cwd: projectRoot, stdio: "ignore" });
369
- const commitMsg = `docs(sdd): transition to phase ${args.nextPhase} - ${args.reason.replace(/"/g, '\\"')}`;
369
+ const commitMsg = `docs(sdd): transición a fase ${args.nextPhase} - ${args.reason.replace(/"/g, '\\"')}`;
370
370
  execSync(`git commit -m "${commitMsg}"`, { cwd: projectRoot, stdio: "ignore" });
371
371
  gitStatus = ` [Git: Rama '${branchName}' actualizada con commit semántico]`;
372
372
  }
@@ -25,7 +25,7 @@ permission:
25
25
  ## DO
26
26
  - Ejecuta `sdd_archive_and_commit` con:
27
27
  - `changeName`: nombre del cambio
28
- - `commitMessage`: mensaje semántico
28
+ - `commitMessage`: mensaje semántico detallado redactado obligatoriamente en **ESPAÑOL** (siguiendo Conventional Commits, ej: `feat(sdd): ...`, `fix(sdd): ...`)
29
29
  - `bumpType`: patch / minor / major
30
30
 
31
31
  ## RETURN
@@ -11,6 +11,11 @@ permission:
11
11
  tools:
12
12
  "sdd_transition": allow
13
13
  "sdd_ui_auditor": allow
14
+ "sdd_secret_scanner": allow
15
+ "sdd_security_vulnerability_scanner": allow
16
+ "sdd_visual_regression_diff": allow
17
+ "sdd_auto_api_mocker": allow
18
+ "sdd_spec_compliance_linter": allow
14
19
  ---
15
20
 
16
21
  # @sdd-builder
@@ -22,6 +27,9 @@ permission:
22
27
  ## DO
23
28
  - Implementa los cambios en el código según el spec, asegurándote de revisar `.openspec/brain.md` para cumplir estrictamente con los patrones técnicos exitosos y evitar reintroducir malas prácticas.
24
29
  - Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos).
30
+ - **Escaneo SAST Quirúrgico**: Ejecuta `sdd_security_vulnerability_scanner` sobre tus archivos modificados antes de cerrar tu implementación.
31
+ - **Validación de Secretos**: Corre `sdd_secret_scanner` para asegurarte de no dejar tokens/passwords temporales de desarrollo.
32
+ - **Linter de Especificación**: Ejecuta `sdd_spec_compliance_linter` para certificar que todos los criterios de aceptación del Spec estén cubiertos.
25
33
  - Valida con LSP (`documentSymbol`, `goToDefinition`).
26
34
 
27
35
  ## RETURN
@@ -42,9 +50,9 @@ permission:
42
50
  - ❌ Escribir o autogenerar suites de tests unitarios o de integración
43
51
  - ❌ Ejecutar validación de linter o auditorías UI por cuenta propia (delegar a `@sdd-tester`)
44
52
  - ❌ Realizar deploys, pushes, o publicaciones de ningún tipo
45
- - ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor` únicamente)
53
+ - ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_secret_scanner`, `sdd_security_vulnerability_scanner`, `sdd_visual_regression_diff`, `sdd_auto_api_mocker`, `sdd_spec_compliance_linter`)
46
54
  - ❌ Modificar `package.json`, `tsconfig.json`, o archivos de configuración de proyecto
47
55
  - ❌ Ignorar el spec.md — toda implementación debe trackear contra los criterios de aceptación del spec
48
56
 
49
57
  > [!IMPORTANT]
50
- > SÓLO DEBE hacer: implementar cambios quirúrgicos según spec.md, usar `sdd_ui_auditor` cuando edite HTML/JSX/TSX, invocar `sdd_transition` al completar
58
+ > SÓLO DEBE hacer: implementar cambios quirúrgicos según spec.md, usar `sdd_ui_auditor` cuando edite HTML/JSX/TSX, validar con SAST y Linter de Spec, e invocar `sdd_transition` al completar.
@@ -20,29 +20,33 @@ permission:
20
20
  - `.openspec/brain.md` (Cerebro del Proyecto: memoria técnica y lecciones históricas)
21
21
 
22
22
  ## DO
23
- - Escanea la estructura del proyecto y lee el `.openspec/brain.md` para entender el mapa técnico y reglas arquitectónicas previas.
24
- - Identifica archivos principales y sus propósitos
25
- - Detecta stack tecnológico y dependencias
26
- - Genera `diagnostics.md` en `.openspec/` orientando la exploración con el contexto del Cerebro.
23
+ - Escanea de forma exhaustiva la estructura del proyecto completo y lee el `.openspec/brain.md` para asimilar las directivas arquitectónicas globales.
24
+ - **IMPORTANTE**: Genera un diagnóstico **GENERAL Y TOTALMENTE REUTILIZABLE** del proyecto completo. Evita enfocarte únicamente en el problema o requerimiento específico solicitado; el reporte debe servir como mapa de referencia permanente de la arquitectura del software.
25
+ - Asegura que cualquier archivo generado o guardado dentro de la carpeta `.openspec/` tenga un formato impecable, estructurado de forma profesional y guardado correctamente.
26
+ - Identifica los archivos principales, patrones de diseño y propósitos de cada módulo.
27
+ - Detecta stack tecnológico, dependencias clave y flujos del sistema.
27
28
 
28
29
  ## WRITE
29
30
  - `.openspec/diagnostics.md`
30
31
 
31
32
  ## FORMAT (diagnostics.md)
32
33
  ```markdown
33
- # Diagnóstico del Proyecto
34
+ # Diagnóstico General del Proyecto
34
35
 
35
- ## Stack Tecnológico
36
- - [tecnologías detectadas]
36
+ ## 📌 Resumen Arquitectónico
37
+ - [Breve descripción general del diseño y patrón del software]
37
38
 
38
- ## Estructura
39
- - [archivos principales]
39
+ ## 🛠️ Stack Tecnológico
40
+ - [Tecnologías principales detectadas en todo el codebase]
40
41
 
41
- ## Dependencias
42
- - [paquetes npm principales]
42
+ ## 📁 Estructura del Código Fuente
43
+ - [Mapa jerárquico y descripción de los módulos principales del proyecto]
43
44
 
44
- ## Puntos de Entrada
45
- - [archivos principales]
45
+ ## 📦 Dependencias y Paquetes Clave
46
+ - [Dependencias npm/bibliotecas core relevantes para el diseño general]
47
+
48
+ ## 🚀 Puntos de Entrada e Integración
49
+ - [Archivos de inicio, enrutadores y puntos de integración clave]
46
50
  ```
47
51
 
48
52
  ## RETURN
@@ -11,6 +11,12 @@ permission:
11
11
  tools:
12
12
  "sdd_transition": allow
13
13
  "sdd_brain_sync": allow
14
+ "sdd_requirement_tracker": allow
15
+ "check_dependency_cooldown": allow
16
+ "sdd_diff_impact_analyzer": allow
17
+ "sdd_auto_api_mocker": allow
18
+ "sdd_test_scaffold_generator": allow
19
+ "sdd_context_pruner": allow
14
20
  ---
15
21
 
16
22
  # @sdd-planner
@@ -23,6 +29,10 @@ permission:
23
29
  ## DO
24
30
  - **Descubrimiento de Requerimientos (Crucial)**: Realiza una encuesta inicial activa al usuario utilizando la herramienta `question` (consolidada en una llamada de 3-5 preguntas claras) para comprender a fondo la causa raíz, el síntoma real de negocio/UX y sus preferencias antes de redactar el plano técnico.
25
31
  - **Consultar el Cerebro**: Analiza `.openspec/brain.md` para asimilar fallas y aprendizajes anteriores. Es obligatorio diseñar una solución técnica que **evite cometer el mismo error o comportamiento incorrecto dos veces**.
32
+ - **Analizar el Impacto del Cambio**: Ejecuta `sdd_diff_impact_analyzer` para determinar el radio de impacto estructural del requerimiento.
33
+ - **Scaffolding de Pruebas TDD**: Usa `sdd_test_scaffold_generator` para autogenerar la suite de pruebas unitarias en base a las especificaciones del `spec.md` diseñado.
34
+ - **Mock de Servicios de Terceros**: Usa `sdd_auto_api_mocker` para extraer endpoints y generar mocks rápidos si el cambio interactúa con APIs externas.
35
+ - **Optimizar Contexto**: Usa `sdd_context_pruner` para limpiar logs o historial redundante de context activo.
26
36
  - Analiza el requerimiento e identifica los archivos y funciones a modificar (indicando rangos de líneas exactos).
27
37
  - Detecta si hay funciones duplicadas en múltiples archivos.
28
38
 
@@ -70,11 +80,11 @@ Feature: [Breve descripción]
70
80
  - ❌ Escribir, modificar o eliminar ningún archivo de código fuente (.ts, .js, .tsx, .jsx, .css, .html)
71
81
  - ❌ Ejecutar comandos bash de ejecución (npm install, git push, npx, etc.) — solo `bash: ask` para lecturas
72
82
  - ❌ Realizar deploys, pushes o publicaciones
73
- - ❌ Crear tests, suites de validación, o archivos de reporte fuera del spec.md
83
+ - ❌ Crear tests, suites de validación, o archivos de reporte fuera del spec.md y el scaffold de pruebas
74
84
  - ❌ Modificar archivos fuera de `.openspec/changes/<change-name>/specs/spec.md`
75
85
  - ❌ Hacer preguntas por goteo (una por turno) — todas las preguntas van consolidadas en UNA sola llamada a `question` (máx 3-5)
76
- - ❌ Usar herramientas más allá de las asignadas (`sdd_transition`, `sdd_brain_sync`)
86
+ - ❌ Usar herramientas más allá de las asignadas (`sdd_transition`, `sdd_brain_sync`, `sdd_requirement_tracker`, `check_dependency_cooldown`, `sdd_diff_impact_analyzer`, `sdd_auto_api_mocker`, `sdd_test_scaffold_generator`, `sdd_context_pruner`)
77
87
  - ❌ Reabrir fases anteriores o retroceder el ciclo
78
88
 
79
89
  > [!IMPORTANT]
80
- > SÓLO DEBE hacer: analizar requerimiento, identificar archivos afectados, realizar encuesta consolidada, generar spec.md
90
+ > SÓLO DEBE hacer: analizar requerimiento, identificar archivos afectados, realizar encuesta consolidada, generar spec.md, y andamiar tests TDD.
@@ -11,6 +11,17 @@ permission:
11
11
  "sdd_transition": allow
12
12
  "sdd_ui_auditor": allow
13
13
  "sdd_spec_validator": allow
14
+ "sdd_regression_detector": allow
15
+ "sdd_bdd_tester": allow
16
+ "sdd_requirement_tracker": allow
17
+ "sdd_diff_impact_analyzer": allow
18
+ "sdd_security_vulnerability_scanner": allow
19
+ "sdd_visual_regression_diff": allow
20
+ "sdd_performance_regress_profiler": allow
21
+ "sdd_auto_api_mocker": allow
22
+ "sdd_test_scaffold_generator": allow
23
+ "sdd_spec_compliance_linter": allow
24
+ "sdd_sandbox_patcher": allow
14
25
  ---
15
26
 
16
27
  # @sdd-tester
@@ -23,14 +34,15 @@ permission:
23
34
  ## DO
24
35
  1. **Detección de Regresiones Históricas**: Lee `.openspec/brain.md` para identificar qué fallas específicas o comportamientos errados ocurrieron en el pasado. Debes verificar de manera explícita y prioritaria que la nueva implementación **no reintroduzca ninguno de los bugs o comportamientos incorrectos registrados en el Cerebro**.
25
36
  2. **Identificar Ecosistema Tecnológico**: Inspecciona la raíz del codebase (archivos como `package.json`, `requirements.txt`, `pyproject.toml`, `platformio.ini`, `CMakeLists.txt`, `go.mod`, etc.) para detectar el stack técnico del proyecto.
26
- 3. **Ejecutar Linter & Auditorías**:
27
- - **JS/TS**: Ejecuta `npm run lint` o `eslint` y las validaciones estáticas de DOM (`npx vitest run tests/static/...`).
28
- - **Python**: Ejecuta `flake8`, `pylint` o `black --check`.
29
- - **C++ (ESP32/Embedded)**: Ejecuta chequeos estáticos como `cppcheck` o verifica la compilación del firmware.
30
- - **Otros**: Usa el formateador/linter estándar del ecosistema detectado.
31
- 4. **Ejecutar Suite de Pruebas**: Usa tu permiso de terminal (`bash`) para correr la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run` en Node, `pytest` / `python -m unittest` en Python, `pio test` en PlatformIO/C++, `go test` en Go, etc.).
32
- 5. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
33
- 5. **Autocorrección**: Corrige errores simples de sintaxis o fallas de test (máx 3 intentos).
37
+ 3. **Validación y Auditorías**:
38
+ - Ejecuta `sdd_spec_compliance_linter` para cruzar requerimientos.
39
+ - Ejecuta `sdd_security_vulnerability_scanner` para detectar vulnerabilidades en el código.
40
+ - Corre `sdd_visual_regression_diff` para auditar la interfaz y estilos.
41
+ - Ejecuta `sdd_performance_regress_profiler` para medir latencias y rendimiento.
42
+ - Usa `sdd_diff_impact_analyzer` para calcular el radio de impacto final.
43
+ 4. **Ejecutar Suite de Pruebas**: Corre la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run`).
44
+ 5. **Autocorrección con Patcher**: Si detectas fallos unitarios simples, invoca `sdd_sandbox_patcher` para aplicar correcciones automáticas inmediatas sin retroceder de fase.
45
+ 6. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
34
46
 
35
47
  ## WRITE
36
48
  - `.openspec/changes/<change-name>/validation_report.md`
@@ -69,10 +81,10 @@ permission:
69
81
  - ❌ Modificar lógica de negocio, funciones, componentes o cualquier código fuente
70
82
  - ❌ Crear, modificar o eliminar specs o spec.md
71
83
  - ❌ Realizar deploys, pushes, o publicaciones
72
- - ❌ Reescribir archivos de código — solo autocorregir errores de sintaxis simples (máx 3 intentos)
84
+ - ❌ Reescribir archivos de código — solo autocorregir errores de sintaxis simples usando `sdd_sandbox_patcher`
73
85
  - ❌ Escribir tests unitarios o de integración nuevos
74
86
  - ❌ Modificar archivos fuera de `.openspec/changes/<change-name>/`
75
- - ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_spec_validator`)
87
+ - ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_spec_validator`, `sdd_regression_detector`, `sdd_bdd_tester`, `sdd_requirement_tracker`, `sdd_diff_impact_analyzer`, `sdd_security_vulnerability_scanner`, `sdd_visual_regression_diff`, `sdd_performance_regress_profiler`, `sdd_auto_api_mocker`, `sdd_test_scaffold_generator`, `sdd_spec_compliance_linter`, `sdd_sandbox_patcher`)
76
88
 
77
89
  > [!IMPORTANT]
78
- > SÓLO DEBE hacer: ejecutar linter, auditorías UI, validaciones estáticas, generar `validation_report.md`, invocar `sdd_transition` al completar
90
+ > SÓLO DEBE hacer: ejecutar linter, auditorías UI, validaciones estáticas, generar `validation_report.md`, invocar `sdd_transition` al completar.
package/agents/zugzbot.md CHANGED
@@ -112,4 +112,5 @@ Ciclo cerrado (solo si 100% tasks completed)
112
112
  - ❌ Delegar a un agente fuera de la fase que corresponde según el lockfile
113
113
 
114
114
  > [!IMPORTANT]
115
- > SÓLO DEBE hacer: leer lockfile, delegar a agente correspondiente, mostrar roadmap, verificar tareas pendientes, invocar `sdd_transition` para avanzar fases
115
+ > SÓLO DEBE hacer: leer lockfile, delegar a agente correspondiente, mostrar roadmap, verificar tareas pendientes, invocar `sdd_transition` para avanzar fases.
116
+ > Todos los archivos generados dentro de `.openspec/` (ej: spec.md, diagnostics.md, validation_report.md, deployment_report.md, sdd-lock.json) deben quedar impecablemente estructurados y guardados con rigurosidad profesional.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "zugzbot-sdd",
3
- "version": "1.5.18",
3
+ "version": "1.5.20",
4
4
  "description": "Zugzbot SDD Swarm - Spec-Driven Development Harness for OpenCode",
5
5
  "main": "index.js",
6
6
  "type": "module",
@@ -0,0 +1,23 @@
1
+ # Skill: SDD Auto Rollback Recovery
2
+
3
+ Enseña a los agentes (principalmente `@sdd-deployer`) cómo actuar quirúrgicamente ante un fallo en la fase de despliegue para restaurar la estabilidad de forma atómica.
4
+
5
+ ## Trigger
6
+
7
+ - Falla del comando de despliegue en Fase 4.
8
+ - Respuestas HTTP 5xx o fallos graves en pruebas de salud inmediatamente después del despliegue.
9
+
10
+ ## Procedimiento de Recuperación
11
+
12
+ 1. **Rollback en Control de Versiones**:
13
+ - Identificar el último commit estable.
14
+ - Ejecutar: `git revert HEAD --no-edit` o `git checkout [stable-hash]` de forma controlada.
15
+ 2. **Restauración en Producción**:
16
+ - Re-desplegar la versión estable recuperada.
17
+ 3. **Aislamiento del Error**:
18
+ - Escribir un archivo temporal de error en `.openspec/crash_report.md`.
19
+ - Transicionar de regreso a Fase 2 (`sdd-builder`) para corrección del bug.
20
+
21
+ ## Tags
22
+
23
+ #rollback #deploy #git #recovery #stability
@@ -0,0 +1,22 @@
1
+ # Skill: SDD Brain Curator
2
+
3
+ Instruye al `@sdd-archiver` sobre cómo sintetizar y empaquetar aprendizajes en el archivo de memoria `brain.md`, evitando duplicación de contexto y optimizando la comprensión de la IA en futuras iteraciones.
4
+
5
+ ## Trigger
6
+
7
+ - Fase de cierre (Fase 5) antes de archivar de forma atómica.
8
+
9
+ ## Directrices de Curación
10
+
11
+ 1. **Evitar Duplicidad**:
12
+ - Agrupar lecciones similares en un único bullet.
13
+ 2. **Categorización Estricta**:
14
+ - `[Sintaxis/Tipado]`: Errores relacionados con TypeScript, JavaScript o Apps Script.
15
+ - `[Arquitectura]`: Desacoplamiento de componentes.
16
+ - `[Lógica de Negocio]`: Flujos de negocio e interfaces.
17
+ 3. **Formato ultra compacto**:
18
+ - Escribir oraciones de máximo 20 palabras por aprendizaje.
19
+
20
+ ## Tags
21
+
22
+ #brain #lessons #synthesis #memory
@@ -0,0 +1,20 @@
1
+ # Skill: SDD Clean Architecture
2
+
3
+ Instruye al `@sdd-builder` en principios de desacoplamiento modular para evitar la creación de archivos gigantescos que saturen el contexto de edición.
4
+
5
+ ## Trigger
6
+
7
+ - Fase de codificación (Fase 2).
8
+
9
+ ## Directrices de Diseño
10
+
11
+ 1. **Separación de Capas**:
12
+ - UI / Vista desacoplada de la lógica de servicios y APIs.
13
+ 2. **Componentes Puros**:
14
+ - Funciones pequeñas con una única responsabilidad.
15
+ 3. **Tamaño Límite**:
16
+ - Evitar archivos de código fuente de más de 300 líneas. Si exceden, modularizar de inmediato.
17
+
18
+ ## Tags
19
+
20
+ #architecture #modular #clean-code #builder
@@ -0,0 +1,20 @@
1
+ # Skill: SDD Token Economy
2
+
3
+ Enseña a todos los agentes a operar bajo estrictas directrices de ahorro de tokens y optimización contextual para reducir costos y acelerar la velocidad del swarm.
4
+
5
+ ## Trigger
6
+
7
+ - Cualquier operación del ciclo SDD (constante).
8
+
9
+ ## Directrices Operativas
10
+
11
+ 1. **Lecturas Selectivas**:
12
+ - Usar herramientas de visualización de rangos específicos de líneas en vez de leer archivos enteros.
13
+ 2. **Poda de Logs**:
14
+ - Resumir o eliminar logs repetitivos y trazas gigantescas de la consola.
15
+ 3. **Peticiones LSP de Alto Impacto**:
16
+ - Apuntar la navegación a los símbolos/métodos relevantes de la clase específica en vez de recorrer múltiples módulos.
17
+
18
+ ## Tags
19
+
20
+ #tokens #economy #cost #efficiency
@@ -384,7 +384,7 @@ export default tool({
384
384
  // 2. Hacer commit automático de los artefactos .openspec/
385
385
  execSync("git add .openspec/", { cwd: projectRoot, stdio: "ignore" });
386
386
 
387
- const commitMsg = `docs(sdd): transition to phase ${args.nextPhase} - ${args.reason.replace(/"/g, '\\"')}`;
387
+ const commitMsg = `docs(sdd): transición a fase ${args.nextPhase} - ${args.reason.replace(/"/g, '\\"')}`;
388
388
  execSync(`git commit -m "${commitMsg}"`, { cwd: projectRoot, stdio: "ignore" });
389
389
 
390
390
  gitStatus = ` [Git: Rama '${branchName}' actualizada con commit semántico]`;