Curso de Github Spark

Entender que Spark está en public preview y sujeto a cambios funcionales o de disponibilidad.

Revisar la disponibilidad para usuarios con Copilot Pro+ anunciada por GitHub en julio de 2025.

Revisar la disponibilidad para clientes de Copilot Enterprise anunciada por GitHub en septiembre de 2025.

Entender que, en enterprise, Spark debe habilitarse mediante controles de Copilot.

Tener presente que Spark no está actualmente disponible para empresas con GitHub Enterprise Cloud con data residency.

Diferenciar usuario individual, organización, empresa y entorno administrado.

Revisar cómo Spark consume premium requests y cómo puede impactar en costes de Copilot.

Considerar el cambio anunciado por GitHub hacia usage-based billing a partir del 1 de junio de 2026.

Preparar una comunicación interna clara sobre acceso, límites y consumo.

Crear una ficha de viabilidad antes de prometer Spark a un equipo o cliente.

Convertir una idea ambigua en un objetivo de aplicación concreto.

Separar usuario, necesidad, flujo, datos, acciones, pantallas y resultado esperado.

Definir qué problema resuelve la app y qué no debe intentar resolver.

Priorizar una primera versión pequeña antes de pedir demasiadas funciones.

Identificar si el caso encaja con Spark o necesita desarrollo tradicional.

Redactar un brief funcional que Spark pueda interpretar.

Evitar prompts que mezclan producto, diseño, datos, seguridad y negocio sin orden.

Crear criterios de éxito para saber si el prototipo funciona.

Preparar ejemplos de uso, roles y escenarios antes de generar.

Diseñar el primer backlog ligero de la app.

Escribir prompts orientados a producto: objetivo, usuario, pantallas, datos y reglas.

Pedir a Spark que empiece por una versión mínima viable.

Describir interacciones concretas en vez de decir “hazlo bonito y funcional”.

Indicar estructura de información, filtros, estados, formularios y acciones.

Pedir cambios incrementales para no romper lo que ya funciona.

Usar contexto visual y funcional cuando se itera sobre una pantalla existente.

Reformular prompts cuando Spark interpreta mal el alcance.

Separar cambios de interfaz, cambios de datos, cambios de lógica y cambios de IA.

Pedir a Spark que mantenga componentes ya aprobados.

Crear una biblioteca de prompts para patrones habituales de app.

Crear una primera aplicación desde una idea sencilla.

Revisar la vista previa interactiva en tiempo real.

Comprobar navegación, estados, botones, formularios y persistencia.

Pedir una mejora visual sin cambiar la lógica.

Añadir una pantalla secundaria o vista de detalle.

Incorporar filtros, búsqueda o clasificación.

Ajustar textos, nombres, colores y estructura.

Detectar errores de comportamiento antes de seguir añadiendo funciones.

Publicar una primera versión privada.

Documentar qué se ha generado, qué funciona y qué queda pendiente.

Crear pantallas limpias, comprensibles y orientadas a tareas.

Pedir estilos visuales con intención: corporativo, minimalista, operativo, formativo o comercial.

Evitar interfaces sobrecargadas por pedir demasiadas funciones en una pantalla.

Diseñar navegación simple y predecible.

Crear formularios con campos necesarios, validaciones y mensajes claros.

Pedir estados vacíos, estados de carga, errores y confirmaciones.

Revisar accesibilidad visual: contraste, tamaño, foco y comprensión.

Crear layouts responsive para escritorio y móvil.

Ajustar microcopy para que la app parezca profesional.

Validar la experiencia con usuarios antes de evolucionar el prototipo.

Entender cuándo Spark crea almacenamiento de datos automáticamente.

Comprender que Spark usa un almacén key-value gestionado sobre Azure Cosmos DB para registros pequeños, según la documentación oficial.

Diseñar datos sencillos: usuarios, registros, tareas, elementos, categorías y estados.

Evitar estructuras demasiado complejas para un prototipo inicial.

Decidir qué datos deben ser temporales y cuáles persistentes.

Revisar que la app no almacena información sensible sin autorización.

Entender el límite indicado por GitHub de registros de hasta 512 KB por entrada.

Diseñar borrado, edición y actualización de registros.

Comprobar qué ocurre cuando varios usuarios interactúan con la app.

Decidir cuándo el caso exige una base de datos externa o arquitectura propia.

Entender que las apps Spark incorporan autenticación con cuenta de GitHub.

Diferenciar app privada, visible para una organización o visible para todos los usuarios de GitHub.

Configurar visibilidad según el tipo de prototipo.

Usar publicación read-only cuando se quiere mostrar sin permitir edición de contenidos.

Revisar qué implica compartir un enlace a una app publicada.

Evitar hacer pública una app con datos de prueba sensibles.

Comprobar si las políticas enterprise restringen publicación externa.

Definir quién puede ver, probar, editar o colaborar.

Preparar pruebas con usuarios internos antes de abrir acceso.

Documentar decisiones de visibilidad y permisos.

Entender cómo Spark puede añadir funciones inteligentes sin gestionar claves API.

Crear un chatbot sencillo dentro de una app.

Añadir resumen de texto, clasificación, etiquetado o sugerencias.

Revisar que Spark está integrado con GitHub Models para incorporar inferencia a la app.

Editar prompts de sistema que controlan una funcionalidad de IA.

Diseñar límites para que la IA no responda fuera de contexto.

Crear mensajes de error o fallback cuando la IA no pueda ayudar.

Evitar enviar datos sensibles a funciones de IA sin revisión.

Probar la calidad de respuestas con varios casos.

Medir si la función de IA aporta valor real a la app.

Revisar el código generado sin miedo, aunque el alumno no sea desarrollador.

Entender la estructura típica de una app Spark en React y TypeScript.

Localizar componentes, estilos, estado, datos y funciones.

Hacer pequeños cambios guiados en textos, clases, validaciones o componentes.

Pedir a Copilot explicaciones del código antes de editar.

Evitar modificar partes críticas sin entender su efecto.

Comparar cambios hechos por prompt y cambios hechos en código.

Revisar errores de compilación tras una edición manual.

Decidir cuándo conviene que intervenga un desarrollador.

Crear una rutina de revisión de código para prototipos que avanzan.

Entender que Spark usa un stack opinado basado en React y TypeScript.

Reconocer componentes principales de una app moderna.

Diferenciar frontend, estado, persistencia, lógica e integración con IA.

Revisar limitaciones al añadir librerías externas.

Entender por qué GitHub recomienda trabajar dentro del SDK y framework de Spark.

Añadir una librería externa solo cuando el caso lo justifica.

Probar bien la compatibilidad después de cualquier dependencia nueva.

Evitar convertir Spark en una app imposible de mantener.

Documentar decisiones técnicas que se salen del patrón estándar.

Preparar una guía de arquitectura ligera para apps Spark.

Abrir la app en GitHub Codespaces directamente desde Spark.

Entender Codespaces como entorno cloud de desarrollo.

Usar Copilot dentro del codespace para revisar, depurar y mejorar.

Sincronizar cambios entre Spark y Codespaces.

Instalar dependencias cuando sea necesario.

Ejecutar la app, revisar logs y solucionar errores.

Preparar cambios técnicos más complejos que no conviene hacer solo con prompt.

Mantener una rama o flujo de trabajo claro si se trabaja en equipo.

Evitar editar en varios sitios sin entender la sincronización.

Usar Codespaces como puente entre prototipo y desarrollo profesional.

Crear un repositorio desde Spark con un clic.

Entender la sincronización bidireccional entre Spark y el repositorio.

Revisar historial de commits y cambios generados.

Añadir colaboradores al repositorio cuando el proyecto lo requiera.

Usar issues para convertir feedback en tareas.

Usar pull requests para revisar cambios antes de fusionar.

Crear project boards para organizar evolución del prototipo.

Evitar que todo el trabajo quede atrapado en una demo sin control de versiones.

Documentar decisiones de producto dentro del repositorio.

Preparar un README claro para cada Spark.

Entender qué aporta GitHub Actions a un proyecto nacido en Spark.

Crear workflows básicos de validación, build o revisión.

Usar Actions con prudencia para no sobredimensionar prototipos.

Revisar cómo Dependabot ayuda a mantener dependencias actualizadas.

Entender riesgos de dependencias vulnerables en apps que se publican.

Configurar alertas o revisiones de seguridad cuando el proyecto crece.

Preparar checks antes de aceptar pull requests.

Evitar pipelines complejos en prototipos demasiado inmaduros.

Crear un flujo simple de calidad técnica.

Decidir cuándo un Spark necesita disciplina DevOps completa.

Usar Copilot agent mode para tareas concretas dentro del entorno de desarrollo.

Pedir mejoras de código, refactors, corrección de bugs o tests.

Entender que Copilot agent mode puede editar archivos y proponer comandos para completar una tarea.

Delegar tareas a Copilot cloud agent cuando la app está conectada a repositorio.

Asignar issues a Copilot para que trabaje en segundo plano.

Revisar pull requests generadas por agentes antes de aceptar cambios.

Usar agentes para mejorar cobertura de tests, accesibilidad o estructura.

Evitar delegar cambios sensibles sin criterios de revisión.

Mantener trazabilidad de qué hizo Spark, qué hizo Copilot y qué hizo el equipo.

Diseñar una colaboración humano-agente segura y mantenible.

Usar Spark para convertir requisitos en experiencias probables.

Crear prototipos interactivos para entrevistas con usuarios.

Simular flujos críticos antes de invertir en desarrollo completo.

Preparar variantes de una misma idea para comparar.

Medir comprensión, interés, fricción y utilidad.

Evitar confundir “la demo funciona” con “el producto está validado”.

Documentar feedback real dentro del backlog.

Ajustar el prototipo tras pruebas con usuarios.

Decidir si continuar, pivotar o descartar.

Convertir Spark en herramienta de discovery y no solo de demo.

Crear pequeños CRMs internos, gestores de solicitudes o tableros de seguimiento.

Desarrollar calculadoras, catálogos, formularios enriquecidos y dashboards ligeros.

Preparar apps de RRHH, formación, operaciones, soporte o ventas.

Añadir filtros, estados, exportaciones simples y roles básicos.

Identificar cuándo una herramienta interna empieza a necesitar seguridad formal.

Evitar que una app improvisada gestione procesos críticos sin soporte.

Diseñar apps con datos ficticios antes de usar información real.

Preparar instrucciones de uso para el equipo.

Crear procesos de mantenimiento y retirada.

Medir ahorro de tiempo frente al proceso manual.

Crear simuladores de aprendizaje y recursos interactivos.

Diseñar asistentes de preguntas frecuentes sobre procesos internos.

Construir miniapps para practicar decisiones, clasificar casos o seguir itinerarios.

Crear catálogos de cursos, checklists de onboarding o evaluaciones sencillas.

Añadir IA para sugerir respuestas, explicar conceptos o resumir información.

Evitar que la app entregue formación incorrecta sin revisión pedagógica.

Preparar contenidos en formato claro y accesible.

Probar con alumnos o empleados antes de publicar.

Recoger feedback de uso.

Reutilizar patrones de Spark para nuevos recursos formativos.

Crear demos rápidas para explicar una solución a cliente.

Simular flujos de negocio con datos ficticios.

Preparar prototipos personalizados por sector o tipo de comprador.

Generar una app de apoyo a una propuesta comercial.

Evitar prometer que el prototipo ya está listo para producción.

Documentar qué partes son simuladas y qué partes son funcionales.

Usar publicación read-only para mostrar sin riesgo de edición.

Recoger feedback del cliente y convertirlo en backlog.

Crear versiones por oportunidad comercial.

Medir si Spark reduce tiempo de preparación de demos.

Clasificar los datos antes de introducirlos en una app.

Eliminar datos privados antes de publicar o compartir.

Revisar que, por defecto, el almacén de datos de una app publicada puede ser compartido por usuarios de esa app.

Evitar usar Spark para datos financieros, sanitarios, laborales o contractuales sin control enterprise.

Crear datos sintéticos para prácticas y demos.

Revisar visibilidad antes de enviar un enlace.

Definir quién puede modificar datos dentro de la app.

Preparar avisos de uso interno si la app es experimental.

Documentar medidas mínimas de seguridad.

Decidir cuándo el caso exige backend propio y controles avanzados.

Recordar que Spark está en public preview y puede cambiar.

Aceptar que su stack es opinado y no sirve para cualquier arquitectura.

Entender que no todas las librerías externas serán compatibles.

Revisar límites del almacén de datos gestionado.

Identificar casos que requieren base de datos relacional, backend propio o integraciones complejas.

No usar Spark como sustituto de auditoría de seguridad profesional.

Evitar apps críticas sin pruebas, observabilidad y mantenimiento.

Reconocer cuándo una app deja de ser prototipo.

Preparar rutas de salida hacia desarrollo tradicional.

Explicar limitaciones al cliente o dirección con claridad.

Crear escenarios de prueba desde el primer día.

Probar flujo feliz, errores, campos vacíos y casos límite.

Revisar que los datos se guardan, editan y eliminan correctamente.

Comprobar navegación en escritorio y móvil.

Validar mensajes, estados, accesibilidad y usabilidad.

Revisar funciones de IA con entradas buenas, malas y ambiguas.

Crear checklist de aceptación antes de publicar.

Pedir a Copilot que sugiera pruebas adicionales.

Convertir fallos en issues del repositorio.

No publicar una app sin una ronda mínima de QA.

Diseñar interfaces legibles y navegables.

Revisar contraste, tamaños, estados de foco y jerarquía visual.

Añadir textos de ayuda, errores claros y confirmaciones.

Evitar depender solo del color para comunicar estado.

Probar formularios con teclado.

Revisar lenguaje sencillo para usuarios no técnicos.

Crear flujos cortos y comprensibles.

Pedir a Copilot revisiones de accesibilidad.

Añadir la accesibilidad como criterio de aceptación.

Documentar mejoras antes de compartir con usuarios reales.

Probar la app en escritorio, tablet y móvil.

Revisar carga inicial, interacciones y errores visuales.

Evitar pantallas con demasiados elementos.

Reducir datos mostrados cuando no aportan valor.

Comprobar filtros y búsquedas con varios registros.

Detectar lentitud provocada por lógica innecesaria.

Ajustar layouts responsive.

Evitar componentes que se rompen en pantallas pequeñas.

Revisar consumo de funciones de IA si afectan a la experiencia.

Crear criterios mínimos de rendimiento para demos.

Entender que Spark app creation consume premium requests asignadas a Spark.

Revisar allowances de Copilot según plan.

Explicar que GitHub anunció transición a usage-based billing desde junio de 2026.

Medir prompts, iteraciones, agentes y uso de modelos en proyectos intensivos.

Evitar iteraciones innecesarias por falta de brief.

Preparar presupuestos o límites para equipos enterprise.

Revisar consumo en plataformas de billing cuando aplique.

Comunicar a usuarios que “probar sin parar” también puede tener impacto económico.

Definir una política de uso para pilotos.

Relacionar coste con valor generado por prototipo o app interna.

Habilitar Spark desde políticas de Copilot cuando se usa Copilot Enterprise.

Definir organizaciones, equipos y usuarios autorizados.

Revisar controles centralizados, acceso, billing y políticas de Copilot.

Crear criterios para qué tipos de apps pueden publicarse.

Establecer revisión de seguridad para apps internas relevantes.

Controlar repositorios generados desde Spark.

Evitar que proliferan prototipos sin propietario.

Definir owners funcionales y técnicos.

Crear catálogo de apps Spark aprobadas.

Revisar periódicamente apps activas, datos y consumo.

Decidir si la app debe seguir en Spark o migrar a un proyecto formal.

Revisar arquitectura, datos, seguridad, escalabilidad y mantenimiento.

Crear repositorio completo con issues, roadmap y responsables.

Añadir pruebas, revisión de código y pipeline mínimo.

Evaluar si el almacenamiento gestionado sigue siendo suficiente.

Revisar autenticación, permisos y roles.

Planificar integraciones externas si el caso lo exige.

Documentar deuda técnica generada durante prototipado rápido.

Preparar handoff entre negocio, producto y desarrollo.

Convertir el Spark en base realista, no en entrega final automática.

Identificar necesidades de integración con CRM, ERP, bases de datos, APIs o herramientas internas.

Evaluar si Spark puede cubrir la necesidad o solo simularla.

Evitar conectar sistemas reales sin revisión técnica.

Usar datos mock para validar flujos antes de integrar.

Crear pantallas que anticipen integraciones futuras.

Documentar contratos de datos y endpoints necesarios.

Decidir cuándo pasar a backend propio.

Usar repositorio y Codespaces para preparar integración seria.

Revisar credenciales, secretos y permisos.

Diseñar una estrategia gradual de integración.

Usar la app viva como punto de conversación común.

Reemplazar parte de los mockups estáticos por prototipos funcionales.

Convertir feedback de stakeholders en issues concretos.

Separar feedback visual, funcional, técnico y estratégico.

Definir quién puede pedir cambios directamente a Spark.

Evitar que varias personas modifiquen sin coordinación.

Crear rituales de revisión semanal.

Mantener decisiones documentadas.

Usar pull requests para cambios técnicos relevantes.

Reducir silos entre negocio y desarrollo.

Pedir una app enorme en un único prompt inicial.

Confundir prototipo generado con producto acabado.

Publicar una app con datos sensibles.

Añadir librerías externas sin probar compatibilidad.

No crear repositorio y perder trazabilidad de cambios.

Usar prompts contradictorios que rompen la estructura inicial.

No revisar código, accesibilidad ni errores.

Dejar una app sin owner ni mantenimiento.

Ignorar costes o consumo de requests.

Vender al cliente capacidades que Spark no garantiza en public preview.

Crear gestor de solicitudes internas con estados y filtros.

Construir catálogo interactivo de servicios, productos o cursos.

Diseñar dashboard sencillo con datos de ejemplo.

Crear app de onboarding con checklist y recursos.

Preparar simulador de decisión para formación.

Crear asistente con IA para resumir textos o sugerir etiquetas.

Desarrollar app de seguimiento de reuniones o acciones.

Preparar demo comercial para explicar un flujo de negocio.

Construir prototipo UX para validar una idea.

Crear herramienta interna pequeña antes de pedir desarrollo completo.

Seleccionar un caso ficticio o anonimizado con valor real para una empresa.

Redactar brief de producto con usuarios, objetivo, flujos, datos y criterios de éxito.

Crear la primera versión con lenguaje natural.

Iterar interfaz, lógica, datos y experiencia de usuario.

Añadir una función de IA usando GitHub Models si encaja con el caso.

Publicar la app en modo privado o controlado.

Crear repositorio y abrir el proyecto en Codespaces.

Añadir issues, README, criterios de prueba y mejoras pendientes.

Revisar seguridad, datos, accesibilidad, costes y límites técnicos.

Presentar el Spark como prototipo listo para validación, evolución o decisión de paso a producción.