Kiro
Tutorial interactivo

De Kiro básico a experto en Terraform

Aprendé primero con ejemplos simples. Después aplicalo a Terraform sobre MiniStack. Prompts listos para copiar. Progreso guardado en tu navegador.

4 fases 12 misiones ~60 min 💾 Progreso guardado
Empezar ahora → Instalar Kiro
🧭
SteeringReglas permanentes para el equipo
🧠
SkillsConocimiento que Kiro activa solo
🤖
AgentsRevisores con criterio propio
🔌
MCPFuentes externas en tiempo real
🪝
HooksAutomatización por eventos
📋
SpecsPlan antes de escribir código
1

Primeros pasos con Kiro

INSTALACIÓN · PRIMER PROMPT · CONTEXT KEYS
En esta fase no tocamos Terraform todavía. Vamos a entender Kiro con ejemplos simples: un juego, una lista de tareas. Lo importante es aprender a hablar con Kiro.
⬇️
Setup
Instalar Kiro y abrir tu primer proyecto

Kiro es un IDE con IA integrada. Descargalo desde kiro.dev. Funciona en macOS, Linux y Windows.

Terminal
mkdir mi-primer-proyecto
cd mi-primer-proyecto
kiro .

Al abrir Kiro verás 3 zonas principales:

  • 📁 Panel lateral — Explorer, Agents, Specs, MCP, Powers
  • 📝 Centro — Editor de código
  • 💬 Panel derecho — Chat de Kiro (atajo: Cmd+L / Ctrl+L)
💡
Atajos esenciales: Cmd+L abre el chat · Cmd+I edit inline · Cmd+K command palette · Ctrl+\` terminal
Vibe Coding
Tu primer prompt — crea un juego en 30 segundos

Abrí el chat (Cmd+L), asegurate de estar en modo Vibe (dropdown superior) y pegá:

Kiro Chat · Vibe
Crea un juego tipo snake en HTML, CSS y JavaScript.
Un solo archivo index.html con todo dentro.
Diseño minimalista, dark mode.
La serpiente se controla con las flechas del teclado.
Resultado: Kiro crea index.html con el juego funcional. Abrilo con doble click o con Live Server.

Ahora iterá sin cerrar el chat:

Kiro Chat
Hazlo más difícil: que la comida aparezca en lugares aleatorios
y la velocidad aumente cada 5 puntos.
💡
Vibe Coding es rápido pero sin reglas. Cada prompt puede generar código diferente. Para estandarizar, usaremos Steering en la fase 2.
🔗
Context
Context keys — decirle a Kiro qué mirar

Con # en el chat le das contexto específico a Kiro sin copiar/pegar código:

📄 #File
Incluye un archivo específico
📁 #Folder
Incluye toda una carpeta
⚠️ #Problems
Errores actuales del editor
💻 #Terminal
Última salida del terminal
🔀 #Git Diff
Cambios sin commitear

Probalo con el juego que creaste:

Kiro Chat
Revisa #File index.html y dime:
- ¿Tiene buenas prácticas?
- ¿Qué mejorarías?
- ¿El código es accesible?
Resultado: Kiro lee el archivo exacto y te da análisis específico de esas líneas de código.
2

Personalizar Kiro

STEERING · SKILLS · AGENTS
Hacer que Kiro siga tus reglas, tenga tu conocimiento y tenga criterio para revisar. Aún usamos ejemplos simples.
🧭
Steering
Reglas que Kiro siempre sigue

Sin reglas, cada prompt da código distinto. El steering son reglas que Kiro lee automáticamente siempre.

❌ Sin Steering

Prompt 1 → camelCase
Prompt 2 → snake_case
Prompt 3 → kebab-case
Inconsistente

✅ Con Steering

Todos los prompts
siguen las mismas
convenciones.
Consistente

Kiro Chat
Crea un steering file .kiro/steering/convenciones.md
con estas reglas para proyectos web simples.
inclusion: always.

- Máximo 3 archivos (index.html, style.css, app.js)
- No crear carpetas extra (src/, dist/, tests/)
- No package.json, no node_modules
- camelCase para variables y funciones JS
- Comentarios JSDoc en todas las funciones
- Mensajes de error en español
- Tema dark mode por default
- Color principal #a855f7 (morado)

Ahora sin repetir las reglas, pedí otro proyecto:

Kiro Chat
Crea una app de lista de tareas (TODO).
Resultado: Kiro automáticamente crea 3 archivos, usa camelCase, agrega JSDoc, dark mode y color morado. Sin decírselo.
📌
Los steering viven en .kiro/steering/*.md y se comparten con Git. Todo el equipo usa las mismas reglas.
🧠
Skills
Darle conocimiento experto a Kiro

Una skill es conocimiento de dominio que Kiro activa cuando detecta que es relevante.

Steering  =  el QUÉ quiero  (reglas fijas)
Skills    =  el CÓMO se hace (se activa cuando es relevante)
Kiro Chat
Crea una skill .kiro/skills/accesibilidad-web.md con conocimiento
sobre accesibilidad (a11y) en HTML/CSS/JS:

- Elementos semánticos (header, nav, main, article)
- Atributos aria-* cuando aplica
- Contraste de color WCAG AA
- Focus visible en elementos interactivos
- Labels asociados a inputs
- Texto alternativo en imágenes
- Keyboard navigation

Probá que se activa sola:

Kiro Chat
Agrega un formulario de contacto a mi TODO app.
Que sea accesible para usuarios con lectores de pantalla.
Resultado: Kiro detecta "accesible" y activa la skill → genera código con elementos semánticos, aria-labels y contraste correcto.
🤖
Agents
Tu senior developer personal

Un agent es una personalidad con criterio que invocás con @nombre. Como tener un senior revisando tu PR.

Kiro Chat
Crea un agent .kiro/agents/reviewer.md llamado "reviewer".

Rol: senior frontend developer estricto con 10 años de experiencia.
Solo aprueba código que cumpla:
- Funciones con JSDoc completo
- try/catch en operaciones que pueden fallar
- Variables descriptivas (no x, y, tmp)
- Sin console.log olvidados
- Código accesible (a11y básico)

Formato:
- APROBADO ✅ con lista de cosas bien
- RECHAZADO ❌ con lista de issues y cómo arreglarlos

Tono: directo pero constructivo. No aprueba por lástima.

Invocalo con @:

Kiro Chat
@reviewer revisa #File app.js y decidí si iría a producción.
Resultado: Devuelve APROBADO o RECHAZADO con lista de issues específicos. Podés tener varios agents (reviewer, security, ux) y ejecutarlos en paralelo.
3

Automatización y extensión

HOOKS · SPECS · MCP
Hacer que Kiro reaccione solo a eventos, planifique antes de codear y consulte fuentes externas en tiempo real.
🪝
Hooks
Acciones automáticas por eventos

Un hook es una acción que se dispara cuando pasa algo en el IDE: guardás un archivo, creás uno nuevo, hacés commit.

Paso 1: Pedile a Kiro que cree el hook. Importante: el pattern debe ser **/*.js (con doble asterisco) para que detecte archivos en cualquier subcarpeta.

Kiro Chat
Crea un hook llamado "js-quality-check" con estas características:
- Se activa al guardar archivos JavaScript
- Pattern: **/*.js (IMPORTANTE: con doble asterisco para subcarpetas)
- Tipo: fileEdited
- Acción: askAgent
- Debe revisar si hay:
  1. Funciones sin JSDoc
  2. console.log olvidados

Si detecta algo, que me avise en el chat con sugerencias específicas.
⚠️
El pattern es clave:
  • *.js → solo archivos en la raíz del workspace ❌
  • **/*.js → archivos en cualquier subcarpeta ✅

Paso 2: Verificá el hook creado. Buscá el archivo .kiro/hooks/js-quality-check.kiro.hook y asegurate que tenga:

.kiro/hooks/js-quality-check.kiro.hook
{
  "enabled": true,
  "name": "JS Quality Check on Save",
  "version": "1",
  "when": {
    "type": "fileEdited",
    "patterns": ["**/*.js"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Revisa el archivo recién guardado buscando funciones sin JSDoc y console.log olvidados. Reporta con formato: línea, problema y sugerencia."
  }
}

Paso 3: Activá el hook y reiniciá Kiro (los hooks se cargan al iniciar).

  • Panel lateral → Agent Hooks → toggle verde
  • Cmd+Q y volvé a abrir Kiro

Paso 4: Creá un archivo de prueba.

test.js · código "malo" a propósito
// Función sin JSDoc (debería avisarte)
function sumar(a, b) {
  console.log("sumando...");  // console.log olvidado
  return a + b;
}

sumar(2, 3);

Editá el archivo (agregá un espacio), guardá con Cmd+S y mirá el chat.

Resultado esperado: Kiro te avisa en el chat con los 2 problemas detectados.
🛟
Plan B — Si el hook fileEdited no se dispara: usá un hook userTriggered que se activa con un click. Mucho más confiable.
Kiro Chat
Elimina el hook js-quality-check anterior y crea uno nuevo
llamado "review-js" con estas características:
- Tipo: userTriggered (NO fileEdited)
- Acción: askAgent
- Debe revisar el archivo actualmente abierto buscando
  funciones sin JSDoc y console.log olvidados

Así lo activo manualmente desde el panel Agent Hooks.
Después: abrí test.js → panel Agent Hooks → click en ▶️ del hook. Funciona al toque.
💡
Alternativa sin hook: en el chat escribí @reviewer revisa #File test.js — siempre funciona y no depende de que el hook se dispare.
📋
Specs
Planificar antes de codear

El vibe coding es rápido pero impredecible. Los specs invierten tiempo al principio para que salga bien.

⏱️
Importante — los specs son lentos: un spec completo puede tardar 5-15 minutos porque Kiro genera 3 documentos (requirements, design, tasks) y espera tu aprobación en cada paso. Esa es su ventaja (control total) y su costo (más lento que Vibe).
  • Usá Vibe para prototipos y cambios pequeños (30 seg)
  • Usá Spec para features grandes donde el costo de equivocarse es alto

Vibe Coding

Prompt → Código → ¿?
~30 segundos

Spec-Driven

Requirements → Design → Tasks → Código ✓
~5-15 minutos

Cambiá el chat a modo Spec (dropdown superior) y pegá:

Kiro Chat · Spec
Crea un Spec para agregar estas features al TODO app:
- Sistema de categorías (trabajo, personal, urgente)
- Filtros por categoría
- Persistencia en localStorage
- Modo oscuro/claro con toggle
- Export a JSON

Solo ejecuta las tareas obligatorias.
1¿Tipo de spec? → Feature
2¿Cómo empezar? → Requirements-First
3Kiro genera requirements → revisá → yes
4Kiro genera design → revisá → yes
5Kiro genera tasks → elegí Solo requeridas
6Kiro ejecuta las tasks y escribe el código
💡
Cómo acelerar un spec:
  • Elegí "Solo requeridas" en el paso de tasks (no "Todas")
  • Si el scope es grande, dividilo en 2-3 specs más chicos
  • Si un paso no te convence, respondé directo con el cambio (no yes)
  • Para pruebas rápidas, siempre preferí modo Vibe
📌
Si un paso no te convence, no escribas "yes". Pedí cambios específicos y Kiro regenera. Los specs se guardan en .kiro/specs/ como documentación permanente.
🔌
MCP
Conectar Kiro con fuentes externas

Los MCP (Model Context Protocol) son conectores que dan a Kiro acceso a fuentes externas en tiempo real: documentación actualizada, APIs, bases de datos.

Vamos a usar el MCP oficial de AWS Documentation (de awslabs/mcp) para consultar la documentación de AWS en vivo.

📋
Requisito: instalá uvx antes (solo la primera vez):
Terminal
# macOS / Linux
brew install uv
# o
pip install uv

# Verificar
uvx --version

Creá el archivo .kiro/settings/mcp.json:

.kiro/settings/mcp.json
{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Después de guardar el archivo, Kiro se reconecta automáticamente. Verificá en el panel lateral → MCP Servers → debería aparecer aws-docs en verde.

Ahora Kiro puede consultar la documentación oficial de AWS al instante:

Kiro Chat · pregunta simple
Usando el MCP de AWS Docs, buscá las mejores prácticas
de seguridad para buckets S3 y dame un resumen.
Kiro Chat · comparar servicios
Usando el MCP de AWS Docs, compará Lambda vs Fargate
para correr una API con tráfico irregular. ¿Cuál es más barato?
Kiro Chat · troubleshooting
Usando el MCP de AWS Docs, explicame por qué un bucket S3
puede devolver "AccessDenied" aunque la policy parezca correcta.
Dame los 3 errores más comunes y cómo diagnosticarlos.
Resultado: Kiro consulta la documentación oficial en este momento, te da respuestas actualizadas con las URLs exactas de la doc como referencia.
📌
El ecosistema completo de awslabs/mcp incluye muchos más servers:
  • aws-documentation-mcp-server — Docs de AWS (el que acabás de instalar)
  • aws-diagram-mcp-server — Genera diagramas de arquitectura AWS
  • cdk-mcp-server — Asistente para AWS CDK
  • cfn-mcp-server — Asistente para CloudFormation
  • cost-analysis-mcp-server — Estimación de costos
  • core-mcp-server — Gestión de recursos AWS
En la fase 4 sumamos el MCP oficial de Terraform.
4

Aplicar todo a Terraform

DESDE CERO · MINISTACK · STEERING · MCP · AGENT
Ya entendés Kiro. Ahora apliquemos los mismos conceptos a Terraform desde cero. Usaremos MiniStack (emulador local de AWS) para no gastar dinero en la nube. Cada misión tiene requisitos, comandos exactos y verificación.
🏗️
Terraform
Setup — Terraform + MiniStack desde cero

Antes de escribir una sola línea de HCL, preparemos el entorno. Necesitás 3 cosas.

Paso 1: Instalar Terraform.

Terminal · Instalar Terraform
# macOS
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

# Linux
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# Verificar
terraform version

Paso 2: Instalar AWS CLI (para verificar los recursos creados).

Terminal · AWS CLI
# macOS
brew install awscli

# Configurar credenciales dummy (MiniStack no las valida)
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test
export AWS_DEFAULT_REGION=us-east-1

# Verificar
aws --version

Paso 3: Levantar MiniStack (AWS local en Docker).

Terminal · MiniStack
# Levantar MiniStack (la primera vez descarga la imagen)
docker run -d -p 4566:4566 --name ministack ministackorg/ministack

# Verificar que está corriendo
docker ps | grep ministack

# Probar que responde
aws --endpoint-url=http://localhost:4566 sts get-caller-identity
Si todo funciona deberías ver algo como: Account: "000000000000". MiniStack está listo y emula todos los servicios AWS en localhost:4566.
🔧
Comandos útiles para MiniStack:
  • docker stop ministack — pausar
  • docker start ministack — retomar
  • docker rm -f ministack — borrar todo y empezar limpio
🧭
Terraform
Steering de Terraform + MiniStack

Creemos 2 steering files para que Kiro siempre genere código Terraform con nuestras convenciones apuntando a MiniStack.

Steering · Convenciones Terraform
Crea el archivo .kiro/steering/terraform-convenciones.md
con inclusion: always.

Convenciones para proyectos Terraform en este workspace:

- Estructura obligatoria:
  - versions.tf → required_version y required_providers
  - providers.tf → configuración del provider AWS
  - variables.tf → declaración de variables
  - main.tf → recursos
  - outputs.tf → outputs con comandos de verificación
  - locals.tf → valores calculados (si aplica)

- required_version >= 1.6.0
- Provider AWS versión ~> 5.0

- Variables:
  - description obligatoria (en español)
  - type declarado siempre
  - validation cuando aplique

- Outputs:
  - description obligatoria
  - Incluir comandos aws --endpoint-url=http://localhost:4566 de verificación

- Naming:
  - snake_case en recursos, variables, outputs
  - Prefijo con var.project + var.environment

- Tags obligatorios en TODOS los recursos:
  - Project, Environment, ManagedBy = "terraform"
  - Usar default_tags en el provider

- Prohibido hardcodear: regiones, AMIs, account IDs, passwords
- Comentarios en español
- Siempre incluir .gitignore con *.tfstate, .terraform/, *.tfvars
Steering · MiniStack
Crea el archivo .kiro/steering/ministack.md con inclusion: always.

MiniStack es un emulador local de AWS que corre en Docker en el puerto 4566.
Todo proyecto Terraform en este workspace debe configurar el provider AWS
para apuntar a MiniStack.

Configuración obligatoria del provider AWS:

provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  default_tags {
    tags = local.common_tags
  }

  endpoints {
    s3             = "http://localhost:4566"
    sqs            = "http://localhost:4566"
    sns            = "http://localhost:4566"
    dynamodb       = "http://localhost:4566"
    iam            = "http://localhost:4566"
    sts            = "http://localhost:4566"
    secretsmanager = "http://localhost:4566"
    ssm            = "http://localhost:4566"
    cloudwatchlogs = "http://localhost:4566"
    lambda         = "http://localhost:4566"
  }
}

Los outputs deben incluir comandos de verificación con:
  aws --endpoint-url=http://localhost:4566 

Antes de terraform apply, verificar que MiniStack esté corriendo:
  docker ps | grep ministack

Probá sin repetir las reglas:

Kiro Chat
Crea un proyecto Terraform con un bucket S3 llamado "demo".
Resultado: Kiro genera versions.tf, providers.tf, variables.tf, main.tf, outputs.tf apuntando a MiniStack, con tags, snake_case y .gitignore. Todo sin que se lo pidas.

Probá que funciona:

Terminal
terraform init
terraform apply -auto-approve
aws --endpoint-url=http://localhost:4566 s3 ls
terraform destroy -auto-approve
🚀
Proyecto final
Todo junto — MCP Terraform + Agent + Specs

El ejercicio final: combinemos todo (Steering + MCP de Terraform Registry + MCP de AWS Docs + Agent revisor + Specs) para crear infraestructura real.

Paso 1: Agregá el MCP oficial de Terraform a tu mcp.json junto al de AWS Docs.

.kiro/settings/mcp.json
{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" },
      "disabled": false,
      "autoApprove": []
    },
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"],
      "disabled": false,
      "autoApprove": [
        "search_providers",
        "get_provider_details",
        "search_modules",
        "get_module_details"
      ]
    }
  }
}

Paso 2: Creá un agent revisor de Terraform.

Kiro Chat · Agent
Crea el agent .kiro/agents/tf-reviewer.md llamado "tf-reviewer".

Rol: senior DevOps con 10 años de experiencia en Terraform y AWS.
Revisá código Terraform y aprobá solo si cumple:

- Variables con description, type y validation cuando aplique
- Outputs con description e incluyen comandos de verificación
- Tags obligatorios en todos los recursos
- Uso de locals para valores calculados o repetidos
- Sin valores hardcodeados
- for_each preferido sobre count cuando hay config diferente
- Provider AWS apunta a MiniStack (localhost:4566)

Formato de respuesta:
- APROBADO ✅ con lista de cosas bien hechas
- RECHAZADO ❌ con issues numerados: archivo/línea, problema y cómo arreglarlo

Tono: estricto pero constructivo. Nunca aprueba por lástima.
⏱️
Sobre los tiempos de los Specs: un spec completo tarda 5-15 min porque genera 3 documentos (requirements → design → tasks) con aprobación en cada paso. Es lento por diseño — la ventaja es el control total. Para que sea más rápido, dividimos en 2 prompts separados (spec primero, revisión después).

Paso 3: Creá el Spec (sin pedirle MCPs ni agent — eso lo hace solo si tiene el steering).

Kiro Chat · Spec
Crea un Spec para la infraestructura de una "tienda online" en MiniStack:

- S3 bucket para archivos estáticos del sitio
- SQS cola para procesar pedidos
- SNS topic de alertas suscrito a la cola SQS
- DynamoDB tabla de productos (con id como hash_key)
- Secrets Manager con password aleatorio (usar random_password)

Solo ejecutá las tareas obligatorias.
Esto tarda ~5-10 min. Kiro te va a pedir aprobación en cada paso:
  • Requirements → revisá → escribí yes
  • Design → revisá → escribí yes
  • Tasks → elegí Solo requeridas
  • Kiro ejecuta las tasks y genera los archivos .tf
Si algo no te convence, no escribas "yes" — pedí cambios y Kiro regenera ese paso.

Paso 4: Cuando el spec termine, pedí la revisión con el agent (prompt separado, mucho más rápido).

Kiro Chat
@tf-reviewer revisá #Folder ejemplo y decidí si está listo para producción.
💡
¿Por qué 2 prompts separados? Si metés todo en uno solo (spec + MCPs + agent), puede tardar 15-25 min. Separándolo:
  • Prompt 1 (spec): ~5-10 min — Kiro ya consulta los MCPs automáticamente si los tiene configurados
  • Prompt 2 (agent): ~30 seg — revisión instantánea
Mismo resultado, la mitad del tiempo.
🐢
Alternativa: todo en un solo prompt (más lento, ~15-25 min)
Si preferís que Kiro haga todo junto sin intervención, usá este prompt. Tarda más pero no tenés que hacer nada entre medio:
Kiro Chat · Spec (versión completa)
Crea un Spec para la infraestructura de una "tienda online" en MiniStack:

Recursos a crear:
- S3 bucket para archivos estáticos del sitio
- SQS cola para procesar pedidos
- SNS topic de alertas suscrito a la cola SQS
- DynamoDB tabla de productos (con id como hash_key)
- Secrets Manager con password aleatorio (usar random_password)

Flujo de trabajo:
1. Antes de generar código, consultá con el MCP de Terraform la
   documentación actual de cada recurso (aws_s3_bucket, aws_sqs_queue,
   aws_sns_topic, aws_sns_topic_subscription, aws_dynamodb_table,
   aws_secretsmanager_secret, aws_secretsmanager_secret_version).
2. Usá el MCP de AWS Docs para buscar mejores prácticas de seguridad
   para cada servicio.
3. Generá el código siguiendo las convenciones del steering.
4. Al terminar, pedí al agent @tf-reviewer que revise todo.

Solo ejecutá las tareas obligatorias.

Paso 5: Ejecutar contra MiniStack y verificar.

Terminal
cd ejemplo/
terraform init
terraform plan
terraform apply -auto-approve

# Verificar con AWS CLI
EP="--endpoint-url=http://localhost:4566"
aws $EP s3 ls
aws $EP sqs list-queues
aws $EP sns list-topics
aws $EP dynamodb list-tables
aws $EP secretsmanager list-secrets

# Ver el output de Terraform
terraform output

# Limpiar
terraform destroy -auto-approve
🎉
¡Lo lograste! Usaste simultáneamente:
  • Steering — Kiro siguió las convenciones automáticamente
  • MCP de Terraform — consultó el Registry en tiempo real
  • MCP de AWS Docs — buscó mejores prácticas de seguridad
  • Spec — planificó requirements → design → tasks antes de codear
  • Agent — revisó el código final con criterio senior
Y todo corriendo gratis en MiniStack, sin AWS real.
🎓
Próximos pasos:
  • Empaquetá todo esto en un Power y compartilo con tu equipo
  • Sumá más MCPs de awslabs/mcp (diagrams, cdk, cost-analysis)
  • Creá hooks para validar Terraform al guardar (terraform fmt, terraform validate)
  • Cuando estés listo, pasá a AWS real quitando los endpoints del provider

✨ La fórmula de Kiro

Steering  = el QUÉ quiero    → reglas permanentes
Skills    = el CÓMO se hace   → conocimiento que se activa solo
Agents    = el QUIÉN revisa   → personalidad con criterio
Hooks     = el CUÁNDO actuar  → automatización por eventos
Specs     = el PLAN primero   → requirements → design → tasks
MCP       = el DÓNDE buscar   → fuentes externas en tiempo real
Powers    = TODO empaquetado  → distribución para el equipo
Kiro

¿Ya dominás Kiro?

Profundizá en Powers, publicá el tuyo en el registry y compartilo con la comunidad.

🎉 ¡Misión completada!