Cómo completar el Kiro University Challenge

Kiro University Challenge es un recorrido de siete lecciones para aprender distintas capacidades de Kiro mientras construyes un proyecto. Aunque las lecciones se publican de forma separada, la evaluación se realiza sobre una única entrega final en la que debes demostrar cómo has utilizado lo aprendido.

El reto comenzó el 21 de septiembre de 2026 y la entrega final está abierta hasta el 6 de octubre de 2026 a las 06:59 UTC. Las siete lecciones obligatorias pueden completarse con el plan gratuito y, junto con los bonus opcionales, puedes llegar a ganar un máximo de 5.250 Créditos de Kiro.

La idea central es utilizar las siete lecciones como partes de un mismo proceso de desarrollo. Empiezas definiendo el proyecto y, a medida que avanzas, incorporas especificaciones, contexto, automatizaciones, tests, integraciones y agentes. Al final, el repositorio muestra cómo has utilizado Kiro durante todo el proceso.

El proyecto que presentes tiene que haber sido creado durante el reto. El repositorio debe ser público, pertenecer a tu cuenta de GitHub y no puede contener commits anteriores al 21 de septiembre de 2026 a las 16:00 UTC. La cuenta de GitHub utilizada para participar también debe tener al menos tres meses.

Kiro debe ser la herramienta principal utilizada durante el desarrollo y el resultado final debe ser un proyecto funcional. El repositorio también debe incluir el directorio .kiro/, ya que forma parte de la evidencia que los jueces utilizarán para comprobar cómo has configurado y aplicado las capacidades de las distintas lecciones.

Conviene empezar con una idea que puedas llevar hasta un estado funcional durante el periodo del reto. El alcance debería permitirte implementar comportamiento real, añadir tests y conectar las distintas capacidades de Kiro sin convertir la mayor parte del tiempo disponible en trabajo puramente de producto.

A partir de ahí, las siete lecciones pueden incorporarse progresivamente al mismo proyecto.
Puedes encontrar todas las 7 lecciones en Kiro University .

La primera lección se centra en Spec-Driven Development. Una Spec convierte una idea o funcionalidad en una definición estructurada antes de empezar la implementación. Kiro utiliza esa especificación para organizar requisitos, diseño técnico y tareas de desarrollo.

Para aplicar esta lección a tu proyecto, elige una de sus funcionalidades principales y trabaja sobre ella mediante una Spec. El objetivo es que los requisitos expresen con claridad qué comportamiento esperas, que el diseño describa cómo se va a implementar y que las tareas resultantes sirvan para dirigir el trabajo posterior de Kiro.

Las Specs quedan almacenadas dentro de .kiro/specs/ y deberían formar parte del repositorio final. Esto permite que la primera lección tenga continuidad durante el resto del challenge, ya que esos requisitos pueden utilizarse posteriormente para implementar, validar y probar la funcionalidad.

La segunda lección introduce Steering files, el mecanismo que permite mantener contexto e instrucciones persistentes sobre el proyecto. En lugar de proporcionar las mismas convenciones cada vez que interactúas con Kiro, puedes mantenerlas dentro del propio repositorio para que formen parte habitual de su contexto.

La aplicación de esta lección consiste en definir la información que Kiro debería conservar mientras desarrolla tu proyecto. Esto puede incluir el propósito del producto, el stack tecnológico, la estructura del código, convenciones internas o reglas específicas de tu dominio.

Los archivos se mantienen dentro de .kiro/steering/. Su valor aparece cuando las decisiones que has documentado afectan al trabajo posterior de Kiro, porque el agente puede mantener esas convenciones mientras implementa nuevas tareas sin tener que reconstruir ese contexto en cada conversación.

La tercera lección utiliza Hooks para introducir automatizaciones basadas en eventos. Un hook puede ejecutar un comando o enviar un prompt al agente cuando Kiro modifica un archivo, utiliza una herramienta o completa una determinada acción.

Para incorporarlo al proyecto, identifica alguna comprobación o acción repetitiva que tenga sentido ejecutar automáticamente durante el desarrollo. Puede estar relacionada con tests, validación, calidad de código, generación de artefactos o cualquier otra tarea que forme parte de tu flujo habitual.

Los hooks actuales se guardan como configuración dentro de .kiro/hooks/, por lo que también dejan evidencia directa en el repositorio. La parte más importante de esta lección es integrar la automatización dentro del flujo real de trabajo para que el evento, la acción y su resultado puedan verificarse claramente.

La cuarta lección introduce Property-based Testing a través de la funcionalidad Correctness de Kiro. En lugar de definir únicamente inputs concretos y sus resultados esperados, este enfoque parte de propiedades generales que deberían mantenerse para muchos valores diferentes. Kiro genera múltiples inputs e intenta encontrar casos que contradigan esas propiedades.

Esta lección conecta directamente con Spec-driven development. Revisa los requisitos definidos al principio del proyecto e identifica comportamientos que deberían mantenerse independientemente de los valores concretos utilizados. Esos invariantes pueden convertirse en propiedades y Kiro puede utilizarlos para comprobar si la implementación sigue realmente lo especificado.

Actualmente, Property-based Testing está disponible en Kiro IDE, mientras que Specs en general también están disponibles en CLI y Web. Por tanto, aunque estés desarrollando parte del proyecto desde CLI o Web, esta lección requiere pasar por el IDE.

La quinta lección introduce Model Context Protocol (MCP). MCP permite conectar Kiro con servidores externos capaces de proporcionar herramientas, prompts, recursos o acceso a servicios que amplían lo que el agente puede hacer desde el proyecto.

Para aplicar esta lección, identifica una integración externa que tenga relación directa con lo que estás construyendo. El servidor MCP puede proporcionar acceso a documentación, APIs, servicios de desarrollo, fuentes de datos u otras herramientas que aporten algo al proceso.

La configuración por sí sola explica cómo has conectado la herramienta, pero su utilización dentro de una tarea concreta demuestra por qué forma parte del proyecto. La entrega debería permitir entender qué capacidad aporta ese MCP y en qué parte del desarrollo ha participado.

La sexta lección trabaja con Custom Agents. Estos agentes permiten crear configuraciones especializadas en las que puedes definir herramientas disponibles, permisos, contexto y recursos según el tipo de trabajo que quieras delegar.

La forma de aplicarlo a tu proyecto es identificar una responsabilidad suficientemente definida como para beneficiarse de un agente especializado. A partir de ella puedes decidir qué herramientas necesita, qué archivos debería cargar como contexto y qué permisos son apropiados para ese trabajo.

Los agentes de proyecto se almacenan dentro de .kiro/agents/, lo que permite incluir su configuración directamente en el repositorio. También puedes conectarlos con trabajo realizado en lecciones anteriores, proporcionando como recursos la Spec u otros documentos relevantes.

Hay un detalle importante cuando combinas esta lección con Steering: los archivos de Steering no se cargan automáticamente dentro de un Custom Agent. Si quieres que el agente los tenga disponibles, debes añadirlos explícitamente a sus resources.

La séptima lección está dedicada a Powers. Un Power proporciona conocimiento especializado, workflows y herramientas que Kiro puede activar cuando el contexto de la conversación lo requiere. De esta forma, el agente puede disponer de capacidades específicas sin cargar permanentemente todo ese contexto.

Para completar esta parte del proyecto, selecciona un Power relacionado con alguna tecnología o necesidad que aparezca realmente durante el desarrollo. Después utilízalo dentro de una tarea en la que sus conocimientos, skills o herramientas puedan intervenir.

Powers pueden incluir skills, conocimiento especializado e integraciones MCP, y se activan dinámicamente según el trabajo que estás realizando. Esto hace que la última lección encaje bien como una ampliación de las capacidades que ya has ido añadiendo al proyecto.

Las siete lecciones forman una secuencia bastante natural cuando se aplican al mismo proyecto. Specs definen lo que quieres construir y Steering conserva las reglas con las que quieres hacerlo. Hooks añade automatización al flujo de desarrollo y Property-based Testing utiliza los requisitos para comprobar propiedades generales de la implementación.

MCP amplía el proyecto con herramientas externas, Custom Agents permite crear contextos especializados para distintos tipos de trabajo y Powers incorpora conocimiento y capacidades que Kiro puede cargar cuando sean relevantes.

El resultado final debería permitir seguir ese recorrido directamente desde el repositorio. .kiro/ es especialmente importante porque las reglas del reto exigen que incluya el contenido necesario para mostrar claramente cómo has configurado las capacidades requeridas por las lecciones.

La entrega final incluye más que el código. Necesitas un repositorio GitHub público con el proyecto funcional y el directorio .kiro/, además de un vídeo público de entre 30 segundos y 3 minutos mostrando el proyecto funcionando y destacando cómo has incorporado cada lección.

También tienes que publicar el proyecto en X o LinkedIn. La publicación debe contener el repositorio público, una descripción de dos o tres frases, el vídeo, #KiroUniversity, #BuildWithKiro y la etiqueta correspondiente a Kiro. Después debes completar el formulario final con el repositorio, el vídeo, la publicación social y una explicación de cómo incorporaste cada una de las siete lecciones.

La fecha límite es el 6 de octubre de 2026 a las 06:59 UTC. Una vez cerrado el periodo de entrega, las reglas indican que el repositorio debe permanecer sin nuevos commits hasta que finalice el judging, el 20 de octubre de 2026 a las 06:59 UTC o hasta que recibas el email con tu premio, lo que ocurra antes.

La mejor forma de preparar esta entrega es mantener la evidencia de cada lección dentro del proyecto mientras avanzas. Cuando llegue el momento de grabar el vídeo y escribir el formulario final, el repositorio ya debería explicar qué utilizaste, dónde está y qué papel tuvo durante el desarrollo.