Cómo configurar Spec Kit en Claude Code en 2026: especificaciones en lugar de prompts

¿Qué pasó con la programación por intuición en mayo de 2026?#

Un año después, el 4 de febrero de 2026, publicó un hilo retrospectivo:

En su charla en Sequoia Ascent 2026, lo expresó con aún más precisión: «El vibe coding eleva el nivel mínimo: cuánto puede hacer cualquiera en software. La ingeniería agéntica preserva el techo: el estándar de calidad del desarrollo profesional». En el mismo escenario, pronunció una frase que pasó al léxico de la industria: «No puedes introducir vulnerabilidades por hacer vibe coding. Sigues siendo responsable de tu software, como antes».

Dos cosas ocurrieron en paralelo. En septiembre de 2025, GitHub publicó la herramienta Spec Kit, que reunió 107.000 estrellas en 8 meses. En febrero de 2026, AWS publicó un caso de estudio detallado sobre descubrimiento de fármacos que informa de «un 95 % de la lógica de negocio generada a partir de la especificación, con un ahorro de más de 80 horas».

A finales de mayo de 2026, se había formado un consenso en el espacio informativo anglófono: el vibe coding como método de trabajo es el nivel para principiantes. El siguiente paso es el desarrollo basado en especificaciones. Esta guía explica cómo instalar y aplicar el enfoque.

¿Qué es el desarrollo basado en especificaciones usado por Spec Kit?#

La idea central de la metodología se resume en una línea de la documentación oficial de GitHub:

En la práctica, esto se desarrolla en 4 fases (Spec Kit añade una más, una fase cero —la constitución—, que se describe más adelante):

1. Specify - escribe en lenguaje natural una especificación de lo que quieres. QUÉ hacer y POR QUÉ. No CÓMO.
2. Plan - el agente toma la especificación y prepara un plan técnico: qué tecnologías y arquitectura usar y qué componentes incluir.
3. Tasks - el agente divide el plan en tareas específicas y verificables con dependencias.
4. Implement - el agente (o sus subagentes) ejecuta las tareas y escribe el código.

Después de Implement, la versión actual de Spec Kit tiene un paso de verificación llamado Converge: el agente comprueba el código terminado frente a la especificación, el plan y las tareas, y luego añade a tasks.md cualquier elemento que falte. Ejecuta Implement y Converge en un bucle hasta que Converge responda «Converged».

Cada fase es un archivo Markdown independiente en el repositorio. Cada fase es un comando de barra independiente en Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, mientras que la comprobación es /speckit-converge. La documentación de Spec Kit escribe los mismos comandos con un punto (/speckit.specify), pero en Claude Code Spec Kit los instala como habilidades y se invocan con un guion. Si algo sale mal en cualquier paso, edita el archivo Markdown y vuelve a ejecutar la fase siguiente.

Spec Kit es una implementación concreta de SDD. En mayo de 2026 ya tenía más de 30 integraciones con distintos agentes de IA. En un mismo repositorio, Spec Kit funciona igual con Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose y una docena más.

Así, después de una ejecución, tu repositorio contiene no solo código, sino también su especificación, plan y tareas. Un mes después, puedes volver al proyecto, leer spec.md y entender qué se hizo y por qué. Ya no es «el vibe coding olvidó que existe el código»: es la memoria de trabajo del proyecto.

¿Por qué necesita esto quien programa por intuición y no escribe código?#

Spec Kit formaliza la planificación en pasos separados con 4 comandos slash. La lógica es separar «pensar bien las cosas» de «implementarlas» para que ocurran en ventanas de contexto diferentes. Cada etapa recibe un contexto limpio que no se ha saturado con la fase anterior.

Tres beneficios concretos para quien programa por intuición:

• Previsibilidad. Cuando le dices al agente «haz un formulario de registro con confirmación por correo electrónico», este se inventa 10 detalles y se equivoca en tres respecto a lo que tenías en mente. Cuando tienes un spec.md con User Stories, Acceptance Scenarios y marcadores [NEEDS CLARIFICATION] en cada punto incierto, no queda nada que adivinar.
• Memoria del proyecto. Un mes después no recordarás lo que hablaste con el agente en el chat. Pero spec.md, plan.md y tasks.md están en el repositorio, en la carpeta specs/###-feature/, junto al código. Te muestran no solo qué se hizo, sino por qué.
• Escala. En una funcionalidad que involucra 1-2 archivos, apenas se nota la diferencia. En una que involucra 20 archivos y 5 entidades de datos, la diferencia está entre «rehacerlo todo después de 4 horas» y «todo ha llegado a la rama principal después de 4 horas». AWS Kiro demostró una automatización del 95 % de la lógica de negocio a partir de una especificación en el proyecto TargetID.

La principal ilusión del vibe coding es que al principio parece más rápido. Media hora y ya tienes un prototipo. Pero al cabo de una semana, el prototipo se rompe y resulta más fácil tirarlo. El desarrollo basado en especificaciones requiere un poco más de tiempo al principio (una hora en lugar de media hora), pero una semana después sigues trabajando en el mismo repositorio.

Cómo instalar Spec Kit en Claude Code (4 pasos)#

Paso 1. Instala uv. Solo tienes que hacerlo una vez; permanece en tu sistema.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Comprueba que uv se haya instalado:

uv --version

Paso 2. Instala Spec Kit. Un comando:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Compruébalo:

specify --version

Paso 3. Inicializa el repositorio. Ve a la carpeta de tu proyecto (o crea uno nuevo) y ejecuta:

specify init --here --integration claude

La opción --integration claude selecciona Claude Code directamente. Sin ella, Spec Kit te pide que elijas un agente de una lista interactiva y también puede pedirte que elijas un tipo de script (para macOS y Linux, deja sh). Si la carpeta no está vacía, Spec Kit te advertirá que combinará sus archivos con los tuyos: confirma primero tu trabajo y después repite el comando con la opción --force.

Después de eso, aparecerá lo siguiente en el repositorio:

.specify/
  memory/
    constitution.md        # project rules, filled in by /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

Paso 4. Abre Claude Code y comprueba los comandos de barra. Ejecuta esto en la misma carpeta:

claude

En la sesión, escribe /speckit: los comandos speckit-* deberían aparecer entre las sugerencias. Si no aparecen, reinicia Claude Code para que vuelva a leer .claude/skills/. Si ya tienes CLAUDE.md en la raíz del proyecto, Spec Kit lo deja como está: funciona junto a él, en .specify/memory/constitution.md.

Spec Kit también funciona sin Claude Code (es compatible con más de 30 agentes), pero esta guía se centra específicamente en la configuración con Claude. Si quieres instalar dos herramientas de inmediato, consulta las guías aparte sobre cómo configurar CLAUDE.md y el modo Plan en Claude Code.

Spec Kit es el primer bloque de construcción de un «contrato laboral del agente». La configuración completa incluye los tres elementos: un clon de IA (tu metodología en forma de Skills y subagentes), un Segundo Cerebro (la estructura business/ a la que el agente vuelve cada vez) e ingeniería del contexto (Spec Kit, Plan Mode, /compact). Estos son los tres pilares sin los cuales la IA alucina.

Cómo escribir tu primera especificación (Specify)#

En Claude Code, escribe:

/speckit-specify

Entonces el agente te pedirá una descripción de la funcionalidad. En este paso, usa lenguaje sencillo y evita la jerga técnica:

Quiero un formulario de registro en mi aplicación. El usuario introduce un correo electrónico
y una contraseña, recibe un correo de confirmación y, después de confirmarlo,
llega al panel. La confirmación caduca a las 48 horas. Si el correo sigue
sin confirmar, elimina la cuenta durante los 5 minutos posteriores
a ese plazo; nunca elimines una cuenta confirmada.

En este ejemplo ilustrativo se ha aclarado una tolerancia de eliminación de 5 minutos tras el plazo de 48 horas. En un producto real, confirma esa tolerancia antes de Plan; exigir exactamente 48 horas necesita un diseño y pruebas que impongan ese requisito más fuerte. El agente preparará specs/001-registration/spec.md. Ábrelo y verás una estructura como esta:

# Feature Specification: User Registration

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.

### Acceptance Scenarios
1. **Given** I am on the registration page,
   **When** I submit valid email and password,
   **Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
   **When** I land on the dashboard,
   **Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
   **When** cleanup runs within the next 5 minutes,
   **Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
   **When** cleanup runs,
   **Then** the account is not deleted.

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
  email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
  delete still-unconfirmed accounts no later than 5 minutes after that
  deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
  CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
  account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)

Presta atención a los marcadores [NEEDS CLARIFICATION: ...]. Spec Kit los inserta deliberadamente donde el agente no obtuvo una respuesta inequívoca de tu texto. Antes de pasar a la fase Plan, debes responderlos manualmente en spec.md o ejecutar /speckit-clarify; el agente revisará los puntos poco claros y te hará preguntas durante el diálogo.

En Spec Kit, el comando integrado /speckit-clarify sustituye al «hazme preguntas» dicho en voz alta. El efecto es el mismo: no pasas a Plan hasta que no quede ningún marcador [NEEDS CLARIFICATION] en spec.md.

En spec.md no debe haber tecnologías. Nada de menciones a React, Postgres, Prisma o Redis. La especificación describe qué hace el sistema desde la perspectiva del usuario y del negocio. La pila tecnológica llega en la fase siguiente.

¿Qué hace Claude en la fase Plan?#

Cuando spec.md esté listo, ejecuta:

/speckit-plan

Si quieres, pasa pistas sobre las tecnologías directamente en el comando:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude lee tres fuentes: tu spec.md, tu CLAUDE.md (o memory/constitution.md) y el código existente en el repositorio. El resultado es un plan.md con una estructura parecida a esta:

# Implementation Plan: User Registration

## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## Architecture Decisions

### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.

### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.

### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.

## Data Model
See data-model.md

## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests

data-model.md describirá las entidades y sus relaciones. contracts/ contendrá borradores de contratos de API (ya sea YAML de OpenAPI o tipos de solicitud/respuesta de TypeScript). No es código: es una descripción de la intención que Claude convertirá más adelante en rutas reales.

La principal ventaja de la fase Plan es el contexto limpio. Claude no intenta tener presentes a la vez la especificación y la implementación. Primero analiza todo, registra la decisión en un archivo y luego sigue adelante.

Después está el comando opcional /speckit-analyze. Se ejecuta después de la fase Tasks y antes de Implement: revisa el conjunto spec.md + plan.md + tasks.md para detectar contradicciones y comprueba si el plan y las tareas cubren todos los requisitos de la especificación. No edita archivos; solo genera un informe. En esencia, es una comprobación formal de coherencia antes de la implementación.

Cómo dividir el trabajo en tareas (Tasks)#

Una vez que tengas spec.md y plan.md, ejecuta:

/speckit-tasks

Claude amplía el plan y crea tasks.md:

# Tasks: User Registration

## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)

## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)

## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation

## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page

## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
  before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
  and protection of confirmed accounts

## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)

Fíjate en los marcadores parallel-safe y after T-NNN. Este es el grafo de dependencias que luego permite ejecutar varias fases en paralelo. Todo el enfoque de aceleración de Spec Kit se basa en este mecanismo: algunas tareas se pueden asignar a cinco sesiones distintas de Claude Code a la vez, mientras que otras deben ejecutarse estrictamente en secuencia.

Spec Kit lo hace automáticamente con un solo comando, nada más instalarlo.

El comando opcional /speckit-taskstoissues toma tasks.md y crea GitHub Issues a partir de la lista, cada una con un enlace a spec.md. Es útil si trabajas en equipo o quieres hacer seguimiento del progreso mediante GitHub Projects.

Cómo implementar con subagentes (Implement)#

/speckit-implement

Claude empieza con la primera tarea de tasks.md. Cada tarea sigue un ciclo breve: leer los archivos pertinentes, escribir un diff, ejecutar las pruebas, marcar [x]. Los subagentes se invocan automáticamente cuando hace falta: uno aparte para revisar el código, otro para ejecutar el linter y otro para comprobar si hay regresiones.

Y, por separado, sobre las reglas:

En Spec Kit, este ciclo está formalizado. Tienes spec.md como fuente de verdad, plan.md para las decisiones técnicas y tasks.md como lista de comprobación. Si Claude se desvía en cualquier paso, vuelves a la especificación y dices: «Eso no coincide con FR-003; vuelve a hacerlo». Sin prompts largos como «recuerda lo que hablamos...»: todo el historial está en los archivos.

Si has conectado Flujos de trabajo dinámicos en Opus 4.8, puedes poner Spec Kit en modo de automatización completa: un comando /speckit-implement y Claude paraleliza el trabajo, consolida los resultados y los comprueba. El límite es de 1000 subagentes a la vez. Para la mayoría de las funcionalidades, bastan 10-30.

Cuando todas las casillas [x] estén marcadas y la comprobación de la sección siguiente responda «Converged», revisas la PR (o una serie de PR si hay muchas tareas) y la integras. Los artefactos —spec.md, plan.md, tasks.md— permanecen en el repositorio como documentación de la funcionalidad. Un año después, no tendrás que hacer ingeniería inversa para reconstruir la lógica a partir del código.

Cómo comprobar que el agente no se haya dejado nada (Converge)#

/speckit-converge

Primero, el agente resume lo que ha encontrado y asigna niveles de gravedad; después, ofrece uno de dos resultados. «Converged» significa que no hay omisiones, tasks.md permanece idéntico byte por byte y puedes pasar a la revisión. «Tasks appended» significa que se encontraron omisiones, se añadieron a la sección Convergence de tasks.md y el agente te indica cuántas hay.

Converge no edita ni elimina código; su única escritura son las nuevas tareas en tasks.md. Así que puedes ejecutarlo sin preocuparte, pero solo después de que /speckit-implement haya procesado el tasks.md actual. Cada pasada posterior encuentra menos omisiones.

¿En qué se diferencia Spec Kit de CLAUDE.md y Plan Mode?#

Compáralos según 5 características:

En términos de Spec Kit, esto es .specify/memory/constitution.md. Durante la inicialización, Spec Kit puede usar tu CLAUDE.md existente como base para la constitución o crear un archivo independiente junto a él. Yo suelo conservar CLAUDE.md como el «contrato» global (pila, glosario, protocolo de despliegue) y usar la constitución de Spec Kit para reglas específicas de esta forma de trabajo; por ejemplo, «todos los formularios se validan con Zod; no se permiten comprobaciones manuales».

La relación con Plan Mode es más sencilla. Plan Mode es un modo rápido de «planificar antes de escribir código» dentro de una sola sesión. Funciona bien para cambios pequeños (corregir un error, refactorizar una función). Para una funcionalidad grande, Plan Mode se queda corto porque la ventana de contexto de una sesión es demasiado pequeña para un plan de 3000 líneas, como explico directamente en la sesión en directo:

Spec Kit es una herramienta concreta de ingeniería del contexto. Traslada el «mantel de arquitectura» del chat a los archivos. Spec.md permanece en el repositorio y cada nueva sesión de Claude vuelve a leerlo: no tienes que repetirte.

Una configuración para un proyecto grande:

1. CLAUDE.md - pila, glosario y qué no hacer. Está en la raíz.
2. .specify/memory/constitution.md para Spec Kit: reglas específicas de este flujo de trabajo.
3. specs/001-feature-A/spec.md, plan.md, tasks.md - primera funcionalidad.
4. specs/002-feature-B/spec.md, plan.md, tasks.md - segunda funcionalidad.
5. Para el trabajo diario, usa /speckit-implement (para tareas listas) o /plan (una comprobación rápida antes de un cambio).

¿Qué casos reales están dando resultado?#

Casos concretos:

• AWS Kiro: agente de descubrimiento de fármacos. En una publicación del blog de AWS Industries fechada el 18 de febrero de 2026, el equipo describe el proyecto TargetID. Tres desarrolladores, tres semanas y un agente de descubrimiento de fármacos. Las cifras del artículo: Kiro generó más del 95 % del código de la lógica de negocio y ahorró más de 80 horas de desarrollo. Además: «La documentación README escrita por Kiro nos ahorró unas 8 horas» y «un 40 % menos de ciclos iterativos de prompt y corrección».
• Rackspace Technology. En el mismo blog de AWS, Rackspace informa de que «completó 52 semanas de trabajo estimado en solo 3 semanas» y de «un aumento del 90 % en la eficiencia». Ya no se trata de una pequeña funcionalidad, sino de un proyecto empresarial completo.
• Crecimiento de GitHub Spec Kit. A 7 de mayo de 2026, el repositorio tenía 93.000 estrellas; para el 31 de mayo, tenía 107.000. Eso supone +14.000 estrellas en tres semanas. Este ritmo de crecimiento es una señal clara de que el enfoque está ganando cuota de mercado.

Para el lector, esto significa que el enfoque no es teórico: equipos serios ya lo están usando en producción.

¿Cuándo NO es adecuado Spec Kit?#

No es adecuado n.º 1: ediciones pequeñas. Si la tarea es «renombrar una variable», «corregir una errata en el texto» o «añadir un registro», pasar por Specify → Plan → Tasks tardará más que la propia edición. Para ediciones pequeñas, Plan Mode o simplemente un prompt directo en Claude Code es más rápido.

No es adecuado n.º 2: experimentos en directo. Cuando aún no sabes lo que quieres y necesitas «trastear» con la interfaz o montar rápidamente un prototipo para ver «si funciona», una especificación no tiene sentido. El valor reside precisamente en que estás improvisando. A la hora de «jugar con una idea», el vibe es justo lo que funciona, no una especificación.

No es adecuado n.º 3: código heredado con un estado complejo. Un contraargumento sólido: la realidad cambia más rápido que las especificaciones. Por ejemplo, en la facturación de suscripciones, el equipo describió los ciclos de facturación y las normas fiscales, pero una semana después el área de Finanzas pidió el IVA europeo; la especificación quedó obsoleta antes del lanzamiento. Cuando la lógica de negocio evoluciona rápidamente, mantener las especificaciones se convierte en una carga.

Un riesgo adicional es una falsa sensación de control: las estructuras son elegantes, pero los agentes suelen ignorar las instrucciones o, por el contrario, seguir las plantillas al pie de la letra. El resultado es un código estructuralmente correcto que no encaja con tu repositorio particular: la especificación no garantiza que el agente la haya entendido como querías.

En abril de 2026, analistas del sector advirtieron sobre el modelo en cascada: escribir una especificación extensa antes del código es un camino que ya hundió a la industria una vez, en la época de los requisitos de 200 páginas. Desde entonces, los ingenieros han sido cautelosos con este enfoque, y esa cautela está justificada.

Qué hacer al respecto. Sugiero una regla sencilla: compara el tamaño de la funcionalidad con el tiempo necesario para escribir la especificación. Si una funcionalidad tardará menos de 2 horas en implementarse, no escribas una especificación: Plan Mode es más rápido. Si tardará una semana, usa Spec Kit sin duda; el ahorro de tiempo compensará cinco veces la hora dedicada a la especificación. Entre 2 horas y una semana, usa tu criterio, aunque yo personalmente escribo una especificación incluso para funcionalidades de medio día porque el artefacto en el repositorio vale más que los 30 minutos ahorrados.

¿Qué sigue? Cómo integrar Spec Kit en tu proyecto#

Un plan concreto para los próximos 7 días:

• Día 1. Instala uv y Spec Kit (5-10 minutos). Comprueba que los comandos /speckit-* aparezcan en Claude Code. No intentes aplicarlos a un proyecto existente: empieza con uno nuevo.
• Día 2. Elige una funcionalidad real que tengas previsto crear. Ejecuta /speckit-specify con una descripción libre. Abre spec.md, léelo y responde a cada [NEEDS CLARIFICATION]. No te apresures a pasar a Plan.
• Día 3. Ejecuta /speckit-plan con indicaciones sobre tu pila. Lee plan.md, especialmente la sección Architecture Decisions. Si algo no te convence, edítalo manualmente.
• Días 4-5. Ejecuta /speckit-tasks y luego /speckit-analyze para comprobar el conjunto de especificación, plan y tareas; después, ejecuta /speckit-implement. Observa cómo Claude marca [x] en tasks.md. Puede atascarse en algún punto; es normal. Vuelve a spec.md, aclara el requisito y reinicia /speckit-implement con una tarea concreta. Una vez cerradas las tareas, ejecuta /speckit-converge y repite la secuencia Implement y Converge hasta que responda «Converged».
• Días 6-7. Revisa la PR (o la serie de PR). Intégrala. Lee spec.md y plan.md: serán la documentación de la funcionalidad para el próximo año.

Lo que sugiero leer en paralelo:

• Cómo configurar CLAUDE.md en 2026 - la base de la constitución de Spec Kit.
• Plan Mode en Claude Code - una alternativa rápida para tareas pequeñas.
• Ingeniería del contexto en 2026 - por qué funciona Spec Kit.
• Skills, Subagents, MCP o Plugins - qué añadir a Spec Kit para tu flujo de trabajo.
• Flujos de trabajo dinámicos en Claude Code - cómo lanzar muchos subagentes a la vez durante la fase Implement.

El flujo de trabajo completo del contexto: clon de IA + Segundo Cerebro + Ingeniería del Contexto.

Hay más materiales disponibles en Ailoot.