metis-desk/.agents/skills/rdx-solid/SKILL.md

name	description
rdx-solid	Aplica principios SOLID, TDD, código limpio, diseño de software y buenas prácticas de ingeniería al escribir código, implementar funcionalidades, refactorizar, diseñar arquitecturas, revisar código, crear pruebas o depurar errores. Prioriza soluciones correctas, sencillas, mantenibles y coherentes con el proyecto, evitando la sobreingeniería y las abstracciones innecesarias.

rdx-solid · Ingeniería de software

Desarrolla y revisa software con una complejidad proporcional a los requisitos. Este archivo establece el flujo de trabajo y orienta la consulta de las referencias; los criterios técnicos y ejemplos se mantienen en ellas.

Prioridad y aplicación

• Respeta las instrucciones del usuario, las restricciones del proyecto, su AGENTS.md y las herramientas configuradas. Las preferencias de este skill se aplican cuando no exista una convención más específica.
• Preservar la corrección, los contratos, la seguridad y el alcance de la tarea es obligatorio. Comunica cualquier limitación que impida comprobarlo.
• TDD y las preferencias de diseño son adaptables al contexto. Las métricas, la regla de tres y los patrones son heurísticas, no requisitos numéricos ni motivos para introducir abstracciones.
• Una excepción relevante debe tener una justificación técnica; no es necesario documentar excepciones triviales.

Flujo de trabajo

1. Comprender: identifica requisitos, comportamiento existente, consumidores y archivos afectados. Contrasta los supuestos con el código y la documentación; aclara las ambigüedades que puedan cambiar el resultado.
2. Consultar: selecciona las referencias de la tabla según el problema. Lee las secciones pertinentes y combina ámbitos cuando el cambio lo requiera; no cargues todos los documentos por defecto.
3. Implementar: aplica la solución suficiente más sencilla y mantén los cambios dentro del alcance. Reutiliza las herramientas existentes; no aproveches la tarea para renombrar, reformatear o refactorizar áreas independientes.
4. Verificar y entregar: ejecuta las pruebas y comprobaciones de tipos, análisis estático y compilación pertinentes al impacto. Revisa contratos y documentación afectados. Resume cambios, decisiones relevantes y verificaciones; identifica lo pendiente y sus motivos sin atribuir resultados a comprobaciones no ejecutadas.

Referencias según la tarea

Cada documento desarrolla sus criterios, ejemplos y listas de comprobación. Consulta la referencia específica en lugar de reproducir su contenido en este archivo.

Necesidad	Referencia
Ciclo TDD, triangulación, regresión y trabajo con código sin pruebas	tdd.md
Estrategia de pruebas, dobles, contratos, aislamiento y asincronía	testing.md
Responsabilidades, extensión, sustitución, interfaces y dependencias	principios-solid.md
Nombres, funciones, control de flujo, errores, comentarios y formato	clean-code.md
Encapsulación, contratos, composición, entidades, objetos de valor y agregados	diseño-de-objetos.md
KISS, YAGNI, DRY, diseño simple y deuda técnica	complejidad.md
Detectar y priorizar problemas de diseño y refactorizaciones	code-smells.md
Elegir y aplicar un patrón ante una necesidad real	patrones-de-diseño.md
Organización del sistema, límites y selección de estilos arquitectónicos	arquitectura.md
APIs, persistencia, transacciones, seguridad y operación de servicios	arquitectura-backend.md
Componentes, estado, formularios, accesibilidad y consumo de APIs	arquitectura-frontend.md
Contratos, esquemas, paquetes y compatibilidad entre frontend y backend	arquitectura-shared.md
Caracterización, modernización, migraciones y compatibilidad de sistemas heredados	arquitectura-legacy.md
Comparación de alternativas, ADR y decisiones estructurales	arquitectura-decisiones.md

Para cambios arquitectónicos, parte de arquitectura.md y continúa con los ámbitos afectados. Para una corrección o refactorización, combina la guía del área con las de pruebas o diseño que resulten necesarias.

Convenciones adicionales

Las convenciones generales de idioma, nomenclatura y formato se mantienen en clean-code.md, sección 9.4. Conserva las del módulo existente cuando difieran y evita normalizaciones ajenas a la tarea.

Cuando el proyecto no establezca otra norma:

• Escribe TSDoc en castellano. Usa prefijo I en interfaces únicamente si el área del proyecto ya sigue esa convención.
• Guarda la documentación general en docs/, con nombres en castellano y kebab-case. Actualízala cuando cambien contratos o comportamiento; evita documentación innecesaria para cambios triviales.
• En áreas con i18n, reutiliza sus claves y mecanismos; mantén coherentes es y en cuando ambos estén soportados.

Salvaguardas transversales

• No modifiques código de terceros, dependencias o archivos generados salvo autorización expresa; respeta las exclusiones del proyecto y utiliza los generadores correspondientes.
• Al contrastar claves no confiables con propiedades propias, utiliza Object.hasOwn(...) o Object.prototype.hasOwnProperty.call(...). No uses in si las propiedades heredadas no deben admitirse; para Map, utiliza has(...).
• Cuando una tarea deba continuar con información incompleta, elige una alternativa conservadora que preserve el comportamiento existente y declara los supuestos materiales. No inventes requisitos, contratos ni resultados de verificación.