Proyecto propio | Código abierto

clean-arch-scaffold: estandariza cómo tu equipo arranca proyectos .NET

Agent Skill de código abierto (MIT) que genera soluciones .NET con arquitectura limpia de 4 capas —Domain, Infrastructure, Application y la UI que elijas (Web API, Blazor, MVC, Console o MAUI Blazor Hybrid)— usando directamente el SDK oficial de .NET, en vez de escribir cada archivo a mano. El equivalente en .NET de rails generate scaffold.

Qué genera

Domain

Entidades e interfaces de repositorio. Sin dependencias externas — la capa más protegida de la arquitectura.

Infrastructure

DbContext de EF Core e implementaciones de repositorio. Aquí vive todo lo que habla con la base de datos.

Application

Servicios con la lógica de negocio real. Es la única capa que la UI puede llamar — nunca el Repository directo.

UI a elección

Web API, Blazor Web, MVC/Razor Pages, Console, o .NET MAUI Blazor Hybrid (Android/iOS/Windows), delegando siempre a la plantilla oficial de Microsoft.

Tests

Proyecto xUnit conectado a Application, listo para empezar a escribir pruebas desde el primer commit.

Database-first

Si ya existe una base de datos, genera entidades + DbContext directo del esquema real (dotnet ef dbcontext scaffold), en vez de modelarlas a mano.

Ahorro medido (evals reales, no estimaciones)

Comparaciones reales lado a lado —mismo modelo, mismo prompt— entre un agente con el skill disponible y uno sin él, capturadas durante el desarrollo del propio skill.

Fuente: evals.json del repositorio
Escenario Tokens con skill Tokens sin skill Tiempo con skill Tiempo sin skill
Generar solución nueva (4 capas + Web API) 33,217 61,679 33 s 227 s
Agregar entidad Product + CRUD a solución existente 32,963 28,669 31 s 22 s

El primer escenario es el caso ganador para el que se diseñó el skill: ~46% menos tokens y ~7x más rápido, porque el agente ejecuta un comando determinista en vez de redactar a mano ~30 archivos — y en la corrida sin skill, el agente también introdujo un patrón MediatR/CQRS no solicitado, un riesgo de inconsistencia más allá del costo en tokens.

El segundo escenario se reporta con honestidad aunque no favorezca al skill: el SDK de .NET no estaba disponible en ninguno de los dos entornos de esa prueba, así que no se le da mayor peso en las conclusiones.

De tokens a dólares: el ahorro real es tiempo de desarrollador

El ahorro en tokens de cómputo de la API es marginal (centavos por corrida). El ahorro relevante para un equipo es el tiempo humano que ese comando determinista reemplaza. Rangos de tarifa usados abajo: $35–$75 USD/hora (tarifa cargada, de un desarrollador remoto a un senior en EE. UU.) — supuestos declarados, no una medición.

Concepto Tiempo manual (estimado) Tiempo con skill Ahorro a $35/h Ahorro a $75/h
Solución nueva (scaffold inicial, 4 capas + UI) 2–4 h < 5 min $70–$140 $150–$300
Repository + Service por entidad 15–30 min < 1 min $9–$18 $19–$38
Entidades desde BD existente (database-first) 1–2 h < 5 min $35–$70 $75–$150

Proyecto típico (10 entidades)

Componente Cantidad Tiempo manual est. Ahorro USD
Scaffold inicial (4 capas + UI) 1 3 h (punto medio) $105–$225
Repository + Service por entidad 10 3.3 h $117–$250
Total por proyecto ~6.3 h $222–$475

Proyectado para un equipo (5 devs, 8 proyectos/año)

Escala Cálculo Ahorro USD estimado
Por proyecto (8 entidades) 3 h + 8×20 min ≈ 5.7 h $200–$428
8 proyectos/año 5.7 h × 8 $1,600–$3,424 / año

No incluye el valor —real pero no cuantificado aquí— de reducción de deuda técnica y retrabajo por inconsistencias arquitectónicas entre proyectos: en el eval registrado, la corrida sin skill introdujo un patrón MediatR/CQRS no solicitado; deshacer una decisión arquitectónica así ya en producción puede costar días, no minutos.

Propuesta: adoptarlo como estándar de equipo

Más allá del ahorro en horas, el valor estratégico es fijar un marco de trabajo único y determinista para arrancar proyectos —el mismo patrón de capas, la misma separación Repository/Service, las mismas convenciones— sin importar quién en el equipo lo ejecute ni en qué sesión de trabajo.

  • Elimina la deriva de convenciones entre soluciones generadas por personas o sesiones distintas.
  • Reduce la curva de onboarding: un dev que conoce un proyecto generado por el skill ya conoce la forma de todos los demás.
  • Evita que un agente de IA reinterprete silenciosamente el pedido (ej. agregando CQRS/MediatR sin que se pidiera).
  • Separa con disciplina Repository (CRUD puro) de Service (lógica de negocio) desde la primera entidad.
  • Soporta 5 tipos de presentación delegando siempre a la plantilla oficial del SDK de Microsoft — no hay boilerplate propio que se desactualice.

Camino de adopción sugerido

  • Piloto: usarlo en el próximo servicio o módulo nuevo, documentando tiempo real invertido vs. lo estimado aquí.
  • Estandarizar el punto de partida: todo proyecto .NET nuevo arranca con scaffold-solution.sh, no una plantilla ad hoc.
  • Compartir vocabulario de dominio: la misma separación de capas en todos los proyectos evita reinterpretarla cada vez.
  • Contribuir de vuelta: --ui mvc, --ui console y --ui blazor-hybrid están implementados pero aún no verificados end-to-end según el propio repo.

¿Quieres adoptarlo en tu equipo?

Puedo ayudarte a integrarlo a tu flujo de trabajo actual o a adaptarlo a las convenciones específicas de tu organización.

Sitio web: romerodevs.net
Correo: isaac.romero@romerodevs.net