Primeros pasos con Kiro
Kiro es un IDE con IA integrada. Descargalo desde kiro.dev. Funciona en macOS, Linux y Windows.
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)
Cmd+L abre el chat · Cmd+I edit inline · Cmd+K command palette · Ctrl+\` terminalAbrí el chat (Cmd+L), asegurate de estar en modo Vibe (dropdown superior) y pegá:
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.
index.html con el juego funcional. Abrilo con doble click o con Live Server.Ahora iterá sin cerrar el chat:
Hazlo más difícil: que la comida aparezca en lugares aleatorios y la velocidad aumente cada 5 puntos.
Con # en el chat le das contexto específico a Kiro sin copiar/pegar código:
Probalo con el juego que creaste:
Revisa #File index.html y dime: - ¿Tiene buenas prácticas? - ¿Qué mejorarías? - ¿El código es accesible?
Personalizar Kiro
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
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:
Crea una app de lista de tareas (TODO).
.kiro/steering/*.md y se comparten con Git. Todo el equipo usa las mismas reglas.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)
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:
Agrega un formulario de contacto a mi TODO app. Que sea accesible para usuarios con lectores de pantalla.
Un agent es una personalidad con criterio que invocás con @nombre. Como tener un senior revisando tu PR.
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 @:
@reviewer revisa #File app.js y decidí si iría a producción.
Automatización y extensión
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.
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.
*.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:
{
"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+Qy volvé a abrir Kiro
Paso 4: Creá un archivo de prueba.
// 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.
fileEdited no se dispara: usá un hook userTriggered que se activa con un click. Mucho más confiable.
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.
test.js → panel Agent Hooks → click en ▶️ del hook. Funciona al toque.
@reviewer revisa #File test.js — siempre funciona y no depende de que el hook se dispare.El vibe coding es rápido pero impredecible. Los specs invierten tiempo al principio para que salga bien.
- 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á:
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.
Feature✓Requirements-First✓yesyesSolo requeridas- 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
.kiro/specs/ como documentación permanente.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.
uvx antes (solo la primera vez):
# macOS / Linux brew install uv # o pip install uv # Verificar uvx --version
Creá el archivo .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:
Usando el MCP de AWS Docs, buscá las mejores prácticas de seguridad para buckets S3 y dame un resumen.
Usando el MCP de AWS Docs, compará Lambda vs Fargate para correr una API con tráfico irregular. ¿Cuál es más barato?
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.
aws-documentation-mcp-server— Docs de AWS (el que acabás de instalar)aws-diagram-mcp-server— Genera diagramas de arquitectura AWScdk-mcp-server— Asistente para AWS CDKcfn-mcp-server— Asistente para CloudFormationcost-analysis-mcp-server— Estimación de costoscore-mcp-server— Gestión de recursos AWS
Aplicar todo a Terraform
Antes de escribir una sola línea de HCL, preparemos el entorno. Necesitás 3 cosas.
Paso 1: 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).
# 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).
# 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
Account: "000000000000". MiniStack está listo y emula todos los servicios AWS en localhost:4566.docker stop ministack— pausardocker start ministack— retomardocker rm -f ministack— borrar todo y empezar limpio
Creemos 2 steering files para que Kiro siempre genere código Terraform con nuestras convenciones apuntando a MiniStack.
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
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:
Crea un proyecto Terraform con un bucket S3 llamado "demo".
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:
terraform init terraform apply -auto-approve aws --endpoint-url=http://localhost:4566 s3 ls terraform destroy -auto-approve
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.
{
"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.
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.
Paso 3: Creá el Spec (sin pedirle MCPs ni agent — eso lo hace solo si tiene el steering).
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.
- Requirements → revisá → escribí
yes - Design → revisá → escribí
yes - Tasks → elegí
Solo requeridas - Kiro ejecuta las tasks y genera los archivos .tf
Paso 4: Cuando el spec termine, pedí la revisión con el agent (prompt separado, mucho más rápido).
@tf-reviewer revisá #Folder ejemplo y decidí si está listo para producción.
- 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
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:
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.
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
- 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
- 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
endpointsdel 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
¿Ya dominás Kiro?
Profundizá en Powers, publicá el tuyo en el registry y compartilo con la comunidad.