Forem: Antonia Navarrete

Hooks en Kiro: cómo automatizar tareas repetitivas con triggers inteligentes

Antonia Navarrete — Fri, 08 May 2026 05:35:34 +0000

Hooks en Kiro: cómo automatizar tareas repetitivas con triggers inteligentes

¿Cuántas veces al día le pides al agente que revise el linting, que genere tests o que actualice la documentación? Si la respuesta es "muchas", los agent hooks de Kiro son para ti. En lugar de repetir esas solicitudes manualmente, configuras una regla una sola vez y Kiro se encarga del resto, de forma automática y consistente.

En este post vamos a recorrer qué son los hooks, cómo funcionan, qué tipos de triggers tienes disponibles y cómo crear los tuyos desde cero.

¿Qué son los agent hooks?

Los agent hooks son disparadores automáticos que ejecutan una acción predefinida —ya sea un prompt al agente o un comando de shell— cuando ocurre un evento específico en tu IDE.

El sistema funciona en dos pasos:

Detección del evento: Kiro monitorea constantemente eventos como guardar un archivo, terminar una tarea o invocar una herramienta.
Ejecución de la acción: Cuando el evento ocurre, se dispara automáticamente la acción configurada.

Esto transforma la forma en que trabajas. Con hooks bien configurados puedes:

Mantener calidad de código consistente sin esfuerzo manual
Prevenir vulnerabilidades de seguridad desde el momento en que escribes
Reducir la carga cognitiva del equipo
Estandarizar procesos sin depender de que cada persona los recuerde
Crear ciclos de desarrollo más rápidos y predecibles

Los dos tipos de acción

Antes de ver los triggers, es importante entender qué puede hacer un hook cuando se dispara. Hay dos tipos de acción:

Agent Prompt (Ask Kiro)

Defines un prompt en lenguaje natural que se envía al agente cada vez que el hook se activa. El agente responde y actúa sobre él igual que lo haría con cualquier mensaje en el panel de chat. Es la opción correcta cuando la tarea depende del contexto actual del código.

Nota: Las acciones de tipo Agent Prompt consumen créditos, ya que inician un nuevo ciclo del agente.

Shell Command (Run Command)

Defines un comando de shell que se ejecuta localmente en tu máquina. Si el comando termina con exit code 0, su salida (stdout) se agrega al contexto del agente. Si falla, el error (stderr) se envía al agente como notificación. En los triggers Pre Tool Use y Prompt Submit, un fallo también bloquea la operación.

Los Shell Commands son más rápidos (se ejecutan localmente, sin LLM) y no consumen créditos. Son la opción correcta para tareas determinísticas que no dependen del contexto del agente.

Los 10 tipos de trigger disponibles

Kiro ofrece una variedad de triggers para cubrir prácticamente cualquier momento del ciclo de desarrollo.

Prompt Submit

Se activa cuando el usuario envía un prompt al agente. En modo Shell Command, el contenido del prompt es accesible mediante la variable de entorno USER_PROMPT.

Casos de uso:

Agregar contexto adicional relevante al prompt
Bloquear ciertos tipos de solicitudes según su contenido
Registrar todos los prompts en una ubicación central

Agent Stop

Se dispara cuando el agente ha completado su turno y terminó de responder.

Casos de uso:

Compilar el código generado y reportar fallos al agente
Formatear o revisar el código producido por el agente
Revisar los cambios realizados y dar instrucciones adicionales

Pre Tool Use

Se ejecuta justo antes de que el agente invoque una herramienta. En el campo Tool name puedes especificar herramientas concretas o usar categorías predefinidas:

Categoría	Descripción
`read`	Todas las herramientas de lectura de archivos
`write`	Todas las herramientas de escritura de archivos
`shell`	Todas las herramientas relacionadas con comandos de shell
`web`	Todas las herramientas web
`spec`	Todas las herramientas de spec
`*`	Todas las herramientas (built-in y MCP)

También puedes usar prefijos como @mcp, @powers o @builtin para filtrar por origen, e incluso patrones regex como @mcp.*sql.* para herramientas MCP específicas.

Casos de uso:

Bloquear invocaciones de herramientas no autorizadas
Agregar instrucciones adicionales antes de que el agente actúe

Post Tool Use

Se activa después de que el agente invoca una herramienta. Aplica la misma lógica de filtrado que Pre Tool Use.

Casos de uso:

Registrar invocaciones para auditoría
Formatear archivos actualizados después de una escritura
Dar instrucciones adicionales sobre el resultado de la herramienta

File Create

Se dispara cuando se crean archivos nuevos que coinciden con un patrón específico en tu workspace.

Casos de uso:

Generar boilerplate automáticamente para nuevos componentes
Agregar headers de licencia a archivos nuevos
Crear archivos de test en paralelo al crear archivos de implementación

File Save

Se activa cada vez que guardas un archivo que coincide con el patrón configurado. Es el trigger más usado en el día a día.

Casos de uso:

Ejecutar linting y formateo automático
Actualizar archivos relacionados
Generar o actualizar documentación
Correr tests para los archivos modificados

File Delete

Se dispara al eliminar archivos que coinciden con el patrón.

Casos de uso:

Limpiar archivos relacionados automáticamente
Actualizar referencias de imports en otros archivos
Mantener la integridad del proyecto

Pre Task Execution

Se ejecuta antes de que una tarea de spec comience su ejecución (cuando su estado cambia a in_progress).

Casos de uso:

Correr scripts de preparación o configuración del entorno
Validar que los prerequisitos estén cumplidos antes de iniciar
Registrar el inicio de la tarea para tracking

Post Task Execution

Se activa cuando una tarea de spec completa su ejecución (cuando su estado cambia a completed).

Casos de uso:

Correr tests para verificar la corrección de la tarea
Aplicar linting o formateo sobre los archivos modificados
Generar documentación del trabajo completado
Notificar sistemas externos sobre la finalización

Manual Trigger

Se ejecuta a demanda, cuando tú lo decides, mediante un clic en el panel de Kiro.

Casos de uso:

Code reviews puntuales
Generación de documentación bajo pedido
Escaneos de seguridad
Optimización de performance

Tres casos de uso reales

1. Sincronización automática de traducciones

Trigger: File Save | Archivos: locales/en.json

Cada vez que guardas el archivo de traducciones en inglés, el hook detecta qué claves se añadieron o modificaron, revisa todos los demás archivos de idioma, marca las claves ausentes con NEEDS_TRANSLATION y las modificadas con NEEDS_REVIEW, y genera un resumen de los cambios pendientes. El equipo de localización siempre sabe exactamente qué falta.

Instrucciones al agente:
1. Identify which string keys were added or modified
2. Check all other language files for these keys
3. For missing keys, add them with a "NEEDS_TRANSLATION" marker
4. For modified keys, mark them as "NEEDS_REVIEW"
5. Generate a summary of changes needed across all languages

2. Mantenedor de cobertura de tests

Trigger: File Save | Archivos: src/**/*.{js,ts,jsx,tsx}

Al modificar cualquier archivo fuente, el agente identifica las funciones nuevas o cambiadas, verifica si existen tests correspondientes, genera casos de prueba para el código sin cobertura, los ejecuta y actualiza los reportes. La cobertura de tests nunca cae.

Instrucciones al agente:
1. Identify new or modified functions and methods
2. Check if corresponding tests exist and cover the changes
3. If coverage is missing, generate test cases for the new code
4. Run the tests to verify they pass
5. Update coverage reports

3. Generador de documentación bajo demanda

Trigger: Manual Trigger

Con un clic, el agente genera documentación completa del archivo actual: extrae firmas de funciones y clases, documenta parámetros y tipos de retorno, incluye ejemplos de uso basados en el código existente, actualiza el README.md con los nuevos exports y verifica que todo siga los estándares del proyecto.

Instrucciones al agente:
1. Extract function and class signatures
2. Document parameters and return types
3. Provide usage examples based on existing code
4. Update the README.md with any new exports
5. Ensure documentation follows project standards

Cómo crear tu primer hook

Puedes crear hooks de dos maneras desde la sección Agent Hooks del panel de Kiro.

Opción A: con lenguaje natural (recomendado para empezar)

Navega a la sección Agent Hooks en el panel de Kiro
Haz clic en el botón +
Selecciona Ask Kiro to create a hook
Describe en lenguaje natural lo que quieres que haga el hook
Presiona Enter o haz clic en Submit
Revisa la configuración generada, ajusta si es necesario y haz clic en Save Hook

Opción B: configuración manual

Navega a la sección Agent Hooks en el panel de Kiro
Haz clic en el botón +
Selecciona Manually create a hook
Completa los campos del formulario:
- Title: nombre corto del hook
- Description: qué hace el hook
- Event: tipo de trigger (File Save, Post Tool Use, Pre Task Execution, etc.)
- Tool name: para hooks Pre/Post Tool Use, qué herramientas aplican
- File pattern: para hooks de archivo, qué archivos monitorear
- Action: Ask Kiro (prompt al agente) o Run Command (shell)
- Instructions / Command: el prompt o comando a ejecutar
Haz clic en Create Hook

Atajo útil: También puedes abrir el Hook UI desde el Command Palette con Cmd+Shift+P (Mac) o Ctrl+Shift+P (Windows/Linux) y escribiendo Kiro: Open Kiro Hook UI.

Gestión de hooks

Todos tus hooks están accesibles desde la sección Agent Hooks del panel de Kiro.

Activar / desactivar: Haz clic en el ícono de ojo junto al hook, o usa el switch Hook Enabled en la vista de detalle. No necesitas eliminar un hook para pausarlo.
Editar: Selecciona el hook y modifica cualquier campo. Los cambios aplican de inmediato.
Eliminar: Selecciona el hook, haz clic en Delete Hook y confirma. Esta acción no se puede deshacer.
Ejecutar manualmente: Para hooks de tipo Manual Trigger, usa el botón ▷ junto al nombre o el botón Start Hook en la vista de detalle.

Buenas prácticas

Diseño de hooks

Un hook, una responsabilidad. Enfoca cada hook en una sola tarea. Son más predecibles y fáciles de depurar.
Instrucciones claras y sin ambigüedad. Cuando uses Agent Prompt, escribe pasos numerados para operaciones complejas.
Empieza con alcance limitado. Para hooks de archivo, comienza con patrones restrictivos antes de ampliarlos.
Prueba con casos límite. Verifica que el hook maneje contenido inesperado o malformado sin fallar.

Rendimiento

Considera la frecuencia del trigger: hooks que se disparan muy seguido en archivos grandes pueden impactar tu flujo.
Usa patrones de archivo precisos para evitar ejecuciones innecesarias.
Para tareas determinísticas, prefiere Shell Command sobre Agent Prompt: es más rápido y no consume créditos.

Trabajo en equipo

Guarda las configuraciones de hooks en control de versiones para compartirlas con todo el equipo.
Documenta el propósito de cada hook y sus limitaciones conocidas.
Revisa y actualiza los hooks a medida que el proyecto evoluciona.
Elimina hooks que ya no sean necesarios para mantener el flujo limpio.

Hooks + MCP: el siguiente nivel

Los agent hooks se potencian aún más cuando se combinan con servidores MCP (Model Context Protocol). Al integrar MCP, los hooks pueden acceder a herramientas externas y APIs especializadas durante su ejecución.

Algunos ejemplos de lo que puedes lograr:

Verificar que el código respete el design system de Figma al guardar archivos CSS o HTML
Actualizar el estado de tickets en Jira o Asana cuando una tarea de spec se completa
Sincronizar una base de datos a partir de archivos de muestra en el proyecto

Para usarlos, configura los servidores MCP en Kiro y referencia sus herramientas directamente en las instrucciones del hook.

Próximos pasos

Los agent hooks son una de las funcionalidades más poderosas de Kiro para eliminar trabajo repetitivo del día a día. La clave está en identificar qué tareas haces manualmente con más frecuencia y automatizarlas una a una.

Un buen punto de partida: agrega un hook de File Save sobre tus archivos fuente principales con linting automático. Con eso solo ya notarás la diferencia.

[Boost]

Antonia Navarrete — Tue, 28 Apr 2026 21:20:28 +0000

Antonia Navarrete

Apr 28

Kiro Specs: Deja de Improvisar y Empieza a Planificar Features con IA

#ai #beginners #kiro #tutorial

Comments 2

5 min read

Kiro Specs: Deja de Improvisar y Empieza a Planificar Features con IA

Antonia Navarrete — Tue, 28 Apr 2026 21:15:37 +0000

Si alguna vez arrancaste a codear una feature "porque ya sabes lo que hay que hacer" y terminaste reescribiendo todo a mitad del camino... este post es para ti.

Kiro Specs es una de las funcionalidades más poderosas del IDE Kiro, y la mayoría de los devs la ignora porque suena a burocracia. Spoiler: no lo es. Es la diferencia entre vibe coding y desarrollo estructurado con IA.

¿Qué es un Spec en Kiro?

Un Spec (especificación) es un artefacto estructurado que convierte una idea de alto nivel en un plan de implementación detallado, con trazabilidad desde el requisito hasta el código.

Cada vez que creas un Spec, Kiro genera automáticamente tres archivos:

.kiro/specs/mi-feature/
├── requirements.md   → Qué debe hacer el sistema
├── design.md         → Cómo lo va a hacer
└── tasks.md          → Lista de tareas ejecutables

No son documentos para guardar en un cajón. Son artefactos vivos que la IA usa para generar código coherente y trazable.

Los Dos Workflows: ¿Por Dónde Empiezas?

Kiro ofrece dos flujos según tu punto de partida:

🔹 Requirements-First (Requisitos primero)

El flujo más común. Lo usas cuando sabes qué quieres construir pero el cómo es flexible.

Requisitos → Diseño → Tareas → Código

Cuándo usarlo:

Estás construyendo una feature desde cero
El producto manda (customer feedback, historias de usuario)
La arquitectura puede adaptarse a los requisitos
Proyecto greenfield

🔹 Design-First (Diseño primero)

Lo usas cuando ya tienes una arquitectura en mente o restricciones técnicas no negociables.

Diseño → Requisitos → Tareas → Código

Cuándo usarlo:

Tienes un diagrama de arquitectura existente
Hay requisitos no funcionales estrictos (latencia, compliance)
Estás portando diseños desde otra herramienta
Necesitas validar factibilidad técnica antes de comprometerte

La Notación EARS: Requisitos que la IA Entiende (y tú también)

El requirements.md usa EARS (Easy Approach to Requirements Syntax), un estándar de la industria para escribir requisitos sin ambigüedad.

El patrón es simple:

WHEN [condición o evento]
THE SYSTEM SHALL [comportamiento esperado]

Ejemplo: Sistema de autenticación

## Requisito 1: Registro de usuario
WHEN a user submits the registration form with valid email and password
THE SYSTEM SHALL create a new account and send a verification email

## Requisito 2: Validación de formulario
WHEN a user submits the registration form with an already-registered email
THE SYSTEM SHALL display an error message without creating a duplicate account

## Requisito 3: Bloqueo por intentos fallidos
WHEN a user fails to login 5 consecutive times
THE SYSTEM SHALL temporarily block the account for 15 minutes and notify the user

¿Por qué esto importa? Porque cada requisito en formato EARS es:

Inequívoco: no hay lugar para interpretaciones
Testeable: cada uno se convierte directamente en un caso de prueba
Trazable: puedes rastrear cada línea de código hasta el requisito que la originó

El design.md: Arquitectura Generada Automáticamente

Una vez confirmados los requisitos, Kiro genera el design.md con:

Arquitectura del sistema y sus componentes
Diagramas de secuencia
Modelos de datos e interfaces
Stack tecnológico recomendado
Estrategia de manejo de errores
Enfoque de testing

Fragmento de ejemplo:

## Arquitectura del Sistema de Autenticación

### Componentes
- **AuthController**: Maneja las rutas HTTP de autenticación
- **UserService**: Lógica de negocio para gestión de usuarios
- **TokenService**: Generación y validación de JWT
- **EmailService**: Envío de correos transaccionales

### Diagrama de Secuencia: Login

User → AuthController: POST /auth/login
AuthController → UserService: validateCredentials(email, password)
UserService → DB: findUserByEmail(email)
DB → UserService: user record
UserService → UserService: comparePassword(hash)
UserService → TokenService: generateJWT(userId)
TokenService → AuthController: { accessToken, refreshToken }
AuthController → User: 200 OK + tokens

El tasks.md: Tu Roadmap de Implementación

El último archivo que genera Kiro es el más concreto: una lista de tareas ejecutables, con dependencias y estado en tiempo real.

## Tareas de Implementación

- [ ] 1. Configurar la base de datos de usuarios
  - Crear migración para tabla `users`
  - Definir índices para email (unique)
  - Agregar campos: id, email, password_hash, created_at, is_verified

- [ ] 2. Implementar UserService
  - Método `createUser(email, password)`
  - Método `validateCredentials(email, password)`
  - Manejo de errores: DuplicateEmailError, InvalidCredentialsError

- [ ] 3. Implementar TokenService  
  - Generación de JWT con expiración configurable
  - Refresh token con rotación automática
  - Blacklist para tokens revocados

- [ ] 4. Crear AuthController
  - POST /auth/register
  - POST /auth/login
  - POST /auth/logout
  - POST /auth/refresh

- [ ] 5. Tests de integración
  - Happy path: registro → verificación → login
  - Error cases: email duplicado, credenciales inválidas
  - Rate limiting: 5 intentos fallidos → bloqueo

Puedes ejecutar cada tarea individualmente o todas a la vez. Kiro actualiza el estado en tiempo real mientras implementa.

Flujo Completo: Del Prompt al Código

Así se ve el proceso desde cero:

Paso 1: Crear el Spec

En el panel de Kiro, haz clic en + bajo la sección Specs, o escribe en el chat:

Spec: sistema de autenticación con registro por email,
login, logout y reset de contraseña. Debe proteger
contra fuerza bruta y validar formatos de email.

Paso 2: Elegir el workflow

Kiro te pregunta: ¿Feature o Bug fix? Selecciona Feature, luego elige Requirements-First.

Paso 3: Iterar sobre requisitos

Kiro genera el primer borrador de requirements.md. Puedes refinarlo:

Agrega un requisito para que el sistema soporte 
autenticación con Google OAuth como alternativa

Paso 4: Revisar el diseño

Kiro genera design.md. Aquí validas que la arquitectura sea correcta antes de que empiece a generar código. Puedes pedir cambios:

Cambia el storage de sesiones de memoria a Redis
para soportar múltiples instancias del servidor

Paso 5: Ejecutar tareas

Una vez aprobado el diseño, abres tasks.md y ejecutas las tareas. Kiro implementa, y tú revisas.

Cuándo Usar Specs vs. Vibe Coding

No siempre necesitas un Spec. Aquí la guía rápida:

Situación	Usa
Feature compleja con múltiples componentes	Specs
Bug donde las regresiones son costosas	Specs
Necesitas documentación para el equipo	Specs
Prototipo rápido sin objetivos claros	Vibe
Exploración técnica sin entregables	Vibe
Cambio menor de una sola línea	Vibe

Tips para Sacarle el Máximo

1. Itera en los requisitos ANTES de pasar al diseño. El poder de Requirements-First está en definir bien el "qué" antes de comprometerte con el "cómo".

2. Importa requisitos existentes. Si tienes un PRD en Confluence o tickets en Jira, puedes copiar el contenido a un archivo y pedirle a Kiro que genere el Spec desde él:

#mi-prd.md Genera un spec a partir de este documento

3. Usa imágenes de arquitectura. Si tienes un diagrama en draw.io o una foto de la pizarra, puedes incluirlo en tu prompt al usar Design-First. Kiro lo interpreta.

4. Los Specs son vivos. Si cambian los requisitos, no empieces de cero: edita requirements.md y haz clic en Refine en el design.md. Kiro actualiza todo en cascada.

Conclusión

Los Specs de Kiro no son burocracia: son la forma de hacer que la IA trabaje de manera predecible y trazable en features complejas. En lugar de tener un agente que improvisa, tienes uno que sigue un plan que tú aprobaste.

La próxima vez que vayas a arrancar una feature no trivial, antes de escribir la primera línea de código, prueba crear un Spec. El tiempo que "perdés" planificando te lo devuelve duplicado en debugging evitado.

¿Te resultó útil? En el próximo post voy a cubrir **Hooks: cómo automatizar tareas repetitivas con triggers inteligentes en Kiro.