Todos los que construimos con Claude pasamos por lo mismo: le pedís una cosa, él hace otra y termina metiendo features que no pediste. Spec Kit es el toolkit MIT oficial del equipo de GitHub que cambia el orden — vos dictás qué construir, quién va a usarlo y cuál es el resultado final antes que él escriba una línea. Después Claude pregunta lo que no quedó claro, te arma el plan técnico, lo rompe en tareas chicas y va tachando cada una mientras construye · vos aprobás cada paso.
Mapa rápido · saltá al paso que te interese
Paso 1 · instalar
uv + 1 comando
Dos caminos: el comando uv tool install directo, o pegarle a Claude un prompt para que él instale specify-cli por vos.
Paso 2 · los 9 comandos
constitution → specify → plan → tasks → implement
9 slash commands que aparecen adentro de Claude Code después del init. Corrés uno, esperás, pasás al siguiente.
Paso 3 · flujo completo
End-to-end con una to-do app
Mirá el flujo entero: del init al primer release, paso por paso, con qué escribís vos y qué responde Claude.
Spec Kit · github/spec-kit (MIT · oficial)
9 comandos slash · 1 CLI specify · 30+ agentes soportados · Python 3.11+ · uv requerido
Esta entrada destila Spec Kit — el toolkit oficial del equipo de GitHub que mete Spec-Driven Development (SDD) en Claude Code. Cubre los 2 caminos para instalarlo (uv tool install manual o pegarle un prompt a Claude para que lo haga por vos), los 9 slash commands del README en detalle con qué produce cada uno y cuándo correrlo (constitution → specify → clarify → checklist → plan → tasks → taskstoissues → analyze → implement), un flujo end-to-end con una to-do app como ejemplo (paso por paso · qué escribís vos · qué responde Claude · qué archivo aparece), 4 prompts copy-paste en español Latam para constitution / specify / plan / implement, 5 trampas honestas que el reel glossó, una comparación honesta contra /plan mode nativo de Claude Code, y cross-links a 6 guías hermanas — aprende-skill, crea-claude-skills, claude-codex-equipo (workflow paralelo), dominar-cowork (alternativa UI), cual-plan-claude (decidir plan) e instalar-claude-code (paso 0).
Qué cambia · qué es Spec-Driven Development
Todos los que construimos con Claude pasamos por lo mismo: le pedís una cosa, él hace otra y termina metiendo features que no pediste. Spec Kit cambia el orden — vos dictás los specs primero, él escribe después. Es un toolkit MIT oficial del equipo de GitHub que instala un CLI llamado specify y nueve slash commands adentro de Claude Code para que el flujo sea spec-first, no code-first.
01
Qué construir · quién va a usarlo · cuál es el resultado final que querés. Eso son los specs y por eso el toolkit se llama Spec Kit. Antes de la primera línea de código, vos describís todo eso en español, y la herramienta lo guarda como archivos .md en tu repo.
02
En vez de tirar features que vos no pediste, marca cada ambigüedad con [NEEDS CLARIFICATION] y te pregunta. Vos respondés, los specs se cierran. Después del clarify, queda un documento sin agujeros que tanto vos como Claude pueden leer y entender lo mismo.
03
Una vez que los specs están firmes, Claude te tira un plan técnico completo (data models, APIs, decisiones de arquitectura) y lo rompe en tareas chicas numeradas. Después va tachando cada tarea de tasks.md mientras construye. Vos aprobás cada paso antes que avance.
Pero Claude Code ya tiene /plan mode · ¿qué suma Spec Kit?
Plan mode te sirve cuando querés que Claude piense antes de escribir en una conversación. Spec Kit suma cuando querés cosas que plan mode no te da: (1) artefactos persistentes que viven en tu repo y se commitean — constitution.md, spec.md, plan.md, tasks.md no se evaporan al cerrar el chat, (2) una constitution compartida con tu equipo que define principios y restricciones del proyecto para que todos los specs siguientes la respeten, (3) compatibilidad cross-agente — los mismos archivos y comandos te sirven si después saltás a Cursor, Copilot, Gemini o cualquiera de los 30+ agentes soportados. Si trabajás solo en proyectos chicos descartables, plan mode te alcanza. Si construís algo que va a vivir y crecer, Spec Kit es el siguiente nivel.
Paso 1 · instalar specify-cli
Spec Kit es un CLI de Python · necesita 3 cosas instaladas antes. Si nunca tocaste Python en tu Mac, no te asustes — el Camino B le delega todo a Claude, los binarios igual quedan en tu sistema pero no tenés que entender cada paso.
Pre-requisitos · necesitás los 3 antes de instalar specify-cli
Python 3.11 o más nuevo
Verificalo con python3 --version. Si tenés algo viejo (3.9, 3.10), tenés que actualizar primero. En Mac con Homebrew: brew install python@3.11.
git
Verificalo con git --version. Si no lo tenés, en Mac sale con xcode-select --install o brew install git. En Windows bajalo de git-scm.com.
uv · el package manager moderno de Python
El comando universal: curl -LsSf https://astral.sh/uv/install.sh | sh. En Mac con Homebrew también podés: brew install uv. Una vez instalado, uv queda en tu PATH y lo usás para casi todo lo de Python sin enredarte con virtualenvs.
Si ya sos dev y tenés uv en tu Mac, son 30 segundos.
Es el comando que el README oficial te muestra primero. Lo corrés desde tu terminal, queda instalado global, y la próxima vez que abrás Claude Code en cualquier proyecto está disponible. El init genera la estructura .specify/ adentro del proyecto y registra los 9 slash commands para Claude Code.
01
Pegá el primer comando de abajo en tu terminal. Importante: reemplazá vX.Y.Z con el tag de la última release (mirá github.com/github/spec-kit/releases para ver cuál es la actual). Si lo dejás como vX.Y.Z literal, no va a funcionar.
02
Corré specify version (sin doble guión · es el comando real del CLI · si ponés specify --version te tira error). Si te muestra el número de la versión que instalaste, listo. Si te dice command not found, uv no agregó sus tools al PATH — corré uv tool update-shell y reabrí tu terminal.
03
Corré specify init mi-proyecto --integration claude. Esto crea una carpeta nueva con el scaffold .specify/ (memoria, scripts, specs, templates) + un CLAUDE.md a nivel raíz del proyecto, y registra los 9 slash commands para que aparezcan adentro de Claude Code cuando entres a esa carpeta. Si querés inicializar en la carpeta actual en lugar de crear una nueva, usás specify init . o specify init --here.
Lo que ganás · CLI global, scaffold por proyecto
El specify CLI queda instalado una sola vez en tu Mac. Después por cada proyecto nuevo corrés specify init y te genera el scaffold spec-kit adentro de esa carpeta. Si más adelante saltás de Claude a Cursor o Copilot, los archivos .specify/ y los slash commands te siguen funcionando — el CLI soporta 30+ agentes con el mismo --integration flag.
Si nunca instalaste Python ni uv, este camino no asusta.
Abrís Claude Code en cualquier carpeta y le pegás el prompt de abajo. Claude lee los docs oficiales de spec-kit, instala uv si te falta, instala specify-cli, y corre el init de tu primer proyecto. Es más lento que el Camino A (Claude tarda 2-4 minutos en hacerlo manual), pero no tenés que entender cada comando.
01
Puede ser la app de escritorio (claude.ai/download) o desde terminal con claude. Que sea una carpeta vacía donde quieras armar tu proyecto nuevo — Spec Kit va a crear el scaffold ahí adentro.
02
Copiá el prompt que está abajo, pegalo en Claude Code y dejá que lo ejecute. Reemplazá [NOMBRE_DEL_PROYECTO] con el nombre que querés para tu app — sin espacios, en minúsculas, con guiones si necesitás separar palabras.
03
Cuando Claude termine, escribí / en el chat y deberían aparecer comandos que empiezan con /speckit. (constitution, specify, plan, tasks, implement, etc). Si no aparecen, pedile a Claude que verifique que el .specify/ está bien armado y que los slash commands quedaron registrados.
Honest disclosure · este camino no está documentado
El README oficial sólo muestra el comando uv tool install. Este camino es una conveniencia que aprovecha que Claude Code puede leer docs y ejecutar comandos por vos — funciona porque Spec Kit no tiene pasos raros de auth, pero si el equipo de GitHub cambia el método de install a futuro, este camino puede romperse antes que el Camino A. Si algo falla, volvé al manual.
Camino A · los 3 comandos del README oficial
Camino A · paso 1 · instalar specify-cli (reemplazá vX.Y.Z con la última release)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.ZCamino A · paso 2 · verificar la instalación (sin doble guión)
specify versionCamino A · paso 3 · inicializar tu primer proyecto con Claude
specify init mi-proyecto --integration claudeClaude Code lee los docs oficiales, instala uv si te falta, instala specify-cli y corre el init de tu primer proyecto. Reemplazá [NOMBRE_DEL_PROYECTO] antes de pegar.
Quiero instalar Spec Kit (github/spec-kit) en mi sistema y arrancar un proyecto nuevo con integración Claude Code. Pasos que necesito que hagas: 1. Andá a https://github.com/github/spec-kit y leé docs/installation.md y docs/quickstart.md. 2. Verificá si tengo Python 3.11+, git y uv instalados (python3 --version, git --version, uv --version). Si me falta alguno, instalalo primero — uv lo instalás con curl -LsSf https://astral.sh/uv/install.sh | sh. 3. Mirá la última release en github.com/github/spec-kit/releases y guardate el tag (ej. v0.8.11). 4. Corré: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@<TAG-DE-LA-ULTIMA-RELEASE> 5. Verificá con specify version (sin doble guión · si ponés specify --version te tira error). 6. Corré specify init [NOMBRE_DEL_PROYECTO] --integration claude para crear el scaffold del proyecto. 7. Cuando termines, decime qué carpeta creaste, qué archivos quedaron adentro, y confirmá que los slash commands /speckit.* están disponibles en este chat. Si falla algún paso, pará y mostrame el error exacto antes de seguir — no asumas que ya tengo nada.
Esto es lo que aparece adentro de tu carpeta después del init
Después de specify init, esta es la forma exacta de tu carpeta. Es importante entender el árbol porque la mayoría de los 9 slash commands leen y escriben acá adentro · si Claude no encuentra estos archivos, no sabe qué hacer.
mi-proyecto/ ├── .specify/ │ ├── memory/ │ │ └── constitution.md ← /speckit.constitution escribe acá │ ├── specs/ │ │ └── 001-mi-feature/ ← una carpeta por feature · numeradas │ │ ├── spec.md ← /speckit.specify │ │ ├── plan.md ← /speckit.plan │ │ └── tasks.md ← /speckit.tasks │ ├── scripts/ │ │ └── bash/ ← orquestan el flujo (en Windows hay .ps1) │ └── templates/ │ ├── spec-template.md │ ├── plan-template.md │ └── tasks-template.md └── CLAUDE.md ← Claude Code lo lee al abrir un chat
.specify/memory/constitution.md
Los principios del proyecto (stack, governance, restricciones). Vive una sola vez por proyecto · no por feature. La generás con /speckit.constitution la primera vez y la actualizás cuando cambian los principios.
.specify/specs/<NNN-feature>/
Una subcarpeta por cada feature nueva. El número (001, 002, 003) lo crea el CLI automáticamente cuando corrés /speckit.specify. Adentro viven spec.md, plan.md y tasks.md de esa feature específica.
CLAUDE.md (en la raíz · no adentro de .specify/)
El archivo que Claude Code lee primero cuando abrís un chat en la carpeta. Spec Kit lo genera con instrucciones para que Claude sepa que es un proyecto SDD y entienda cómo orquestar los 9 slash commands.
Workflow clave que el reel no mencionó · una rama de git por cada feature.
Spec Kit detecta automáticamente en qué feature estás trabajando mirando tu rama actual de git. Cuando corrés /speckit.specify por primera vez sobre una idea nueva, el CLI te crea una rama nueva con el formato 001-nombre-feature y la subcarpeta .specify/specs/001-nombre-feature/ con el spec.md adentro. Si después te cambiás a otra rama tipo 002-otra-feature, todos los siguientes /speckit.plan, /speckit.tasks y /speckit.implement van a leer y escribir en .specify/specs/002-otra-feature/ sin que vos tengas que decirle nada · Spec Kit lo deduce de la rama. Para alternar entre features: git checkout <rama-de-la-feature>. Para arrancar una feature nueva: te volvés a main y corrés /speckit.specify de nuevo · el CLI numera la siguiente automáticamente.
Paso 2 · los 9 comandos slash
Después del specify init, abrís Claude Code adentro de la carpeta del proyecto y los 9 comandos aparecen como slash commands. Los 6 del flujo principal son obligatorios — los 3 marcados como opcional son gates de calidad que podés saltarte para experimentos rápidos pero conviene correrlos en producción. Corrés uno, esperás a que Claude termine de generar el archivo correspondiente, lo revisás, y pasás al siguiente.
/speckit.constitution
Define los principios del proyecto: stack tecnológico, tamaño del equipo, restricciones de governance, target de deploy. Es como las reglas constitucionales del repo — todo lo que venga después tiene que respetarlas.
Qué produce
memory/constitution.md (o archivo equivalente según la versión del template).
Cuándo correrlo
Primero de todo · una sola vez por proyecto. Después si cambian los principios, lo volvés a correr y se actualiza.
/speckit.specify
Pasa de tu idea suelta a un PRD estructurado con user stories y acceptance criteria. Vos describís qué construir y para quién en español natural · Claude lo convierte en spec formal y marca con [NEEDS CLARIFICATION] cada cosa que quedó ambigua. Atrás de escena, el CLI te crea una rama de git nueva (tipo 001-mi-feature) y una carpeta .specify/specs/001-mi-feature/ donde van a vivir spec.md, plan.md y tasks.md de esta feature en particular.
Qué produce
.specify/specs/<NNN-feature>/spec.md con sus marcadores · más una rama nueva de git para esta feature.
Cuándo correrlo
Después de la constitution · una vez por feature nueva grande. Cada feature corre en su propia rama · para alternar entre features hacés git checkout a la rama correspondiente · Spec Kit deduce sola qué feature estás trabajando.
/speckit.clarify
Te lleva uno por uno por los marcadores [NEEDS CLARIFICATION] del spec. Pregunta, vos respondés, el spec se cierra. No avanza al próximo marcador hasta que el anterior esté resuelto.
Qué produce
spec.md refinado · sin marcadores pendientes.
Cuándo correrlo
Después de specify · obligatorio si querés evitar que Claude invente en el implement.
/speckit.checklist
Genera un checklist de calidad sobre tus specs · verifica completitud, consistencia, claridad de los acceptance criteria. Es un gate opcional pero te ahorra dolor en producción.
Qué produce
Reporte de calidad con items verde/rojo · sin archivo nuevo en el repo.
Cuándo correrlo
Antes de plan · sólo si el proyecto va a producción. Para experimentos descartables podés saltarlo.
/speckit.plan
Traduce los specs a arquitectura técnica: data models con relaciones, contratos de API, componentes, decisiones de arquitectura con su rationale. Verifica compliance contra la constitution antes de cerrar el plan.
Qué produce
plan.md con secciones técnicas + contracts/ (si aplica al stack).
Cuándo correrlo
Después de clarify (o checklist si lo corriste) · una vez por feature grande.
/speckit.tasks
Rompe el plan técnico en tareas chicas numeradas. Cada tarea es ejecutable en un solo paso. Marca cuáles son paralelizables (frontend mientras se hace backend) y cuáles son blocker.
Qué produce
tasks.md con tareas numeradas + grafo de dependencias entre tareas.
Cuándo correrlo
Después de plan · una vez por feature.
/speckit.taskstoissues
Convierte las tareas de tasks.md en issues reales de GitHub. Cada tarea queda como un issue separado con sus labels y dependencies. Útil si trabajás en equipo o querés que el progreso quede tracked en GitHub.
Qué produce
Issues nuevos en el repo de GitHub · cada tarea de tasks.md mappea a un issue.
Cuándo correrlo
Opcional · después de tasks · solo si querés que las tareas vivan en GitHub Issues y no solo en tasks.md local.
/speckit.analyze
Cross-checkea todos los artefactos juntos: constitution, spec, plan, tasks. Busca contradicciones (ej. el spec pide algo que viola la constitution) y gaps (ej. el plan no cubre un acceptance criterion del spec).
Qué produce
Reporte de consistencia · sin archivo nuevo. Si encuentra problemas, los marca para que los resuelvas antes de implementar.
Cuándo correrlo
Antes de implement · opcional pero recomendado en producción.
/speckit.implement
Empieza a escribir el código siguiendo tasks.md. Va tachando cada tarea a medida que la completa y te avisa antes de avanzar a la próxima. Vos aprobás · él sigue. Si una tarea genera un cambio que rompe el spec o el plan, para y te pregunta.
Qué produce
Código fuente del proyecto + tests asociados a las tareas implementadas.
Cuándo correrlo
Último de todo · solo cuando constitution, spec, plan y tasks están firmes y analyze pasó limpio.
Paso 3 · usar · flujo completo end-to-end
Para que se vea concreto, supongamos que querés armar una to-do app llamada Taskify (tipo Todoist liviano). Así se ve el flujo end-to-end con Spec Kit · 7 pasos · cada paso muestra qué escribís vos, qué responde Claude y qué archivo aparece en tu repo.
Vos escribís
En la terminal, fuera de Claude Code: specify init taskify --integration claude
Claude responde
El CLI crea la carpeta taskify/ con la estructura .specify/ adentro (memoria, scripts, specs, templates) y un archivo CLAUDE.md a nivel raíz del proyecto. Los 9 slash commands quedan registrados. No es Claude todavía, es el CLI corriendo en tu terminal — mirá el árbol completo en la sección Paso 1.
Archivo que aparece
Carpeta taskify/ con .specify/memory/, .specify/scripts/, .specify/specs/, .specify/templates/ y CLAUDE.md en la raíz.
Vos escribís
Adentro de Claude Code (cd taskify · claude): /speckit.constitution. Después vos: React + Python FastAPI, equipo de 2, deploy en Vercel para el front y Railway para la API, sin testing complejo en el MVP.
Claude responde
Pregunta detalles sobre governance, escalabilidad esperada, compliance. Vos respondés breve. Cuando cierra, te muestra el contenido de constitution.md.
Archivo que aparece
memory/constitution.md con principios escritos · listo para commitear.
Vos escribís
/speckit.specify. Después: Quiero una app de tareas tipo Todoist liviano. Los usuarios son freelancers que llevan 5+ clientes en paralelo. Features: tasks con tags por cliente, fechas de vencimiento, prioridades, vista 'qué hago hoy' que agrupa por cliente.
Claude responde
Pregunta edges: ¿tasks pueden ser compartidas entre equipos? ¿qué pasa con tasks archivadas? ¿hay límite de tags por cliente? · y marca cada ambigüedad con [NEEDS CLARIFICATION] en el spec.
Archivo que aparece
spec.md con user stories, acceptance criteria y marcadores de ambigüedad.
Vos escribís
/speckit.clarify. Claude te lleva una por una: 'Las tasks compartidas entre equipos · ¿permitís?' Vos: 'No, primero versión single-user'. 'Las archived · ¿persisten o se borran?' Vos: 'Persisten 90 días, después se borran'. Y así.
Claude responde
Pregunta · vos respondés · marca como resuelto · pasa al siguiente. Al final el spec queda sin marcadores [NEEDS CLARIFICATION].
Archivo que aparece
spec.md actualizado · sin agujeros · listo para plan.
Vos escribís
/speckit.plan
Claude responde
Propone: schema de DB (User, Task, Tag, Cliente), endpoints REST (/tasks, /tasks/today, /clients), componentes React (TaskList, TodayView, TagFilter). Justifica cada decisión y verifica que cumple la constitution (deploy Vercel + Railway, sin Redis porque salimos del scope del MVP).
Archivo que aparece
plan.md con secciones técnicas + contracts/ con OpenAPI specs si aplica.
Vos escribís
/speckit.tasks
Claude responde
Genera ~30 tareas numeradas: 01 Create User model, 02 Create Task model, 03 POST /tasks endpoint, ..., 28 Build TodayView component, 29 Wire TagFilter to API, 30 Deploy to Vercel + Railway. Marca cuáles son paralelizables (front y back se pueden hacer en paralelo).
Archivo que aparece
tasks.md con la lista numerada + grafo de dependencias.
Vos escribís
/speckit.implement. Después vos solo aprobás cada tarea cuando termina (ej. 'sigue con la próxima' o 'pará, hay un bug en la 03').
Claude responde
Va tarea por tarea, escribe código + tests, marca como ✓ cuando termina cada una en tasks.md y te avisa antes de avanzar. Si en la tarea 15 descubre que el spec dice algo que no se puede implementar, para y te pregunta antes de cambiar nada.
Archivo que aparece
Código completo del proyecto + tests + tasks.md con ✓ en cada tarea completada.
Prompts copy-paste · 4 fases que importan
Después del specify init y de tener los 9 slash commands disponibles adentro de Claude Code, estos 4 prompts cubren las fases que más importan. Pegalos en Claude Code adentro de la carpeta del proyecto, reemplazá los corchetes con tus datos, y dejá que cada comando termine antes de pasar al siguiente.
Después de correr /speckit.constitution, pegá este prompt para que Claude tenga toda la info de una sola vez en lugar de preguntarte 10 cosas seguidas.
/speckit.constitution Voy a construir [TIPO DE APP · ej. SaaS de gestión de tareas para freelancers]. Mi stack favorito es [STACK · ej. Next.js 15 + Supabase + Tailwind + shadcn/ui]. Mi equipo es [TAMAÑO · ej. solo yo · 2 personas · equipo de 5]. Lo voy a deployar en [HOSTING · ej. Vercel para el front y Supabase managed para la DB]. Mis restricciones: - Mobile-first · responsive desde 320px. - Sin testing pesado en el MVP · sumamos tests cuando llegamos a 100 usuarios. - Sin Redis · sin colas · todo síncrono salvo emails que van por Resend. - Privacidad: nunca guardamos datos sensibles del cliente final del usuario. Definí la constitution del proyecto con principios claros, decisiones de stack justificadas y reglas de governance.
Después de /speckit.specify, pegá este prompt con la descripción de tu app. Es la parte más importante — cuanto más claro escribís acá, menos preguntas te va a hacer Claude después.
/speckit.specify Quiero construir [NOMBRE · ej. Taskify]. Es una [DESCRIPCIÓN EN 1 LÍNEA · ej. app de tareas tipo Todoist liviano]. La gente que lo va a usar es [QUIÉN · ej. freelancers que llevan 5+ clientes en paralelo y se les mezcla qué les toca hacer para cada uno]. El resultado final que quiero es [RESULTADO · ej. que un freelancer abra la app y vea exactamente qué le toca hacer hoy por cliente, sin saltar entre planillas]. Las features clave son: - [FEATURE 1 · ej. tasks con tags por cliente] - [FEATURE 2 · ej. fechas de vencimiento + prioridades] - [FEATURE 3 · ej. vista 'qué hago hoy' agrupada por cliente] - [FEATURE 4 · ej. modo focus que oculta todo lo no-hoy] Pregúntame todo lo que no quede claro antes de cerrar el spec — y marca con [NEEDS CLARIFICATION] cada ambigüedad que descubras mientras armás los acceptance criteria. No quiero sorpresas en el implement.
Después de tener spec.md sin marcadores [NEEDS CLARIFICATION], pegá este prompt para que el plan respete tu constitution sin que tengas que recordárselo.
/speckit.plan Tengo el spec listo y la constitution firmada. Ahora dame el plan técnico completo: - Data models con sus relaciones (esquema de DB exportable a Prisma o SQL). - Contratos de API endpoint por endpoint (OpenAPI si aplica al stack). - Decisiones de arquitectura con su justificación (por qué este patrón y no otro). - Estructura de carpetas del repo (cómo se organiza el código). - Validación explícita contra cada principio de la constitution. Si algo del spec no se puede implementar respetando la constitution, marcalo como conflicto y proponé las 2-3 maneras de resolverlo (cambiar el spec · relajar la constitution · sumar deuda técnica explícita) antes de seguir adelante.
Después de tener tasks.md y opcionalmente analyze limpio, pegá este prompt para arrancar el implement con reglas claras de cómo querés que se comporte.
/speckit.implement Tengo constitution + spec + plan + tasks listos. Empezá a implementar. Reglas no negociables: 1. Vas tachando cada tarea de tasks.md (marca ✓) cuando la termines. 2. Me avisás antes de saltar a la próxima · yo apruebo · vos seguís. 3. Si una tarea genera un cambio en el spec o el plan, parás antes de tocar nada y me preguntás cómo querés que lo resuelva. 4. Los tests los escribís junto con el código de cada tarea · no como tarea aparte al final. 5. Si te trabás en una tarea por más de 2 intentos fallidos seguidos, parás y me decís el problema con la info técnica del error · no entres en loop tratando lo mismo distinto. Arrancá con la tarea 01 y avisame cuando termine para que yo apruebe.
5 trampas honestas
01
El toolkit oficial es github/spec-kit y el CLI se llama specify (paquete specify-cli). Si buscás "specs" en GitHub vas a encontrar 50 paquetes random de PyPI que no tienen nada que ver. Usá siempre la URL oficial github.com/github/spec-kit · ese es el único maintained por el equipo de GitHub.
02
El reel hace parecer que es plug-and-play. En realidad si nunca tocaste Python en tu Mac, hay un setup previo de 5-10 minutos: actualizar Python si tu sistema trae uno viejo, instalar uv, verificar que git esté · entonces sí, instalar specify-cli. El Camino B (pegale a Claude el prompt de install) abstrae esto, pero los binarios igual quedan en tu sistema.
03
El reel habla de Claude porque ese es el ecosistema de tododeia. La realidad es que specify init acepta --integration claude, --integration cursor, --integration copilot, --integration gemini, --integration codex, --integration windsurf, --integration goose, --integration qwen y más. Si después de un mes saltás de Claude a Cursor, los mismos archivos .specify/ y los mismos slash commands te siguen funcionando.
04
Una vez que corriste /speckit.implement y tenés código generado, si volvés a /speckit.specify para cambiar algo grande del producto, hay que regenerar plan → tasks → implement. El código viejo no desaparece pero puede quedar desalineado del nuevo plan. Para experimentos rápidos podés saltarte los gates opcionales (clarify, checklist, analyze) y rebuildear; para producción real, pensá los specs bien antes de implementar.
05
Si solo querés que Claude piense antes de escribir en una conversación de 30 minutos · plan mode te alcanza. Spec Kit suma cuando querés: (a) artefactos persistentes en el repo que se commitean, (b) una constitution compartida con tu equipo que define principios y restricciones para todos los specs futuros, (c) compatibilidad cross-agente · los mismos archivos sirven en Cursor, Copilot, Gemini. Si trabajás solo en proyectos chicos descartables, plan mode te alcanza. Si construís algo que va a vivir y crecer, Spec Kit es el siguiente nivel.
Guía de la comunidad
Esta entrada destila Spec Kit — el toolkit MIT oficial del equipo de GitHub que mete Spec-Driven Development en Claude Code via specify-cli y 9 slash commands. Es parte de la bóveda de tododeia, una colección libre de recursos para quienes construyen con Claude todos los días.
Cierre personal
“Si querés construir cosas con Claude y siempre termina metiendo features que no le pediste, perdele el miedo a la metodología. La primera app que armes con specs antes que código, vas a entender por qué github/spec-kit tiene casi 100 mil estrellas. No es un toolkit más · es la forma en la que el equipo de GitHub piensa que vamos a construir software los próximos 5 años · y por una buena razón.”
Repo oficial · github/spec-kit
Toolkit MIT oficial del equipo de GitHub · ~96k stars · README con install + uso completo. La URL canónica que tenés que linkear · cualquier otra es un fork o paquete random.
Guía de instalación · docs/installation.md
Instrucciones detalladas paso a paso · cubre uv y pipx, mac/linux/windows, troubleshooting de los errores comunes (PATH, permisos, Python viejo). Léela si el Camino A te falla.
Quickstart · docs/quickstart.md
El walkthrough oficial end-to-end con Taskify (la to-do app de ejemplo). Es la fuente del flujo que esta guía describe en español · andá ahí si querés cross-checkear cada paso.
Video oficial · introducción al SDD
Video oficial del equipo de GitHub explicando qué es Spec-Driven Development, por qué lo construyeron y cómo cambia el flujo de construir software con IA. 15 minutos.
Guías hermanas que cruzan con Spec Kit
Aprendé qué son las skills en Claude Code
Spec Kit registra skills markdown adentro de tu proyecto. Si no entendés bien qué es una skill, esta guía cubre el mental model completo antes de seguir.
Creá tu propia skill desde cero
Si Spec Kit te enganchó con el enfoque "templates markdown que Claude lee" y querés armar las tuyas para tus oficios específicos, esta guía te muestra cómo escribir una skill desde cero.
Claude + Codex en equipo · workflow paralelo
Si querés que Codex revise lo que Claude escribió en el implement, esta guía te muestra cómo conectarlos · plan/spec con Claude · auditoría con Codex.
Dominar Claude Cowork · alternativa UI
Si preferís trabajar con interfaz visual en lugar de CLI · Cowork tiene plan mode y skills propias. Comparalo con Spec Kit antes de decidir cuál usar.
Cuál plan de Claude necesitás
Spec Kit no exige plan Max · funciona con Pro $20. Pero el implement consume muchos tokens · si tu proyecto es grande, esta guía te ayuda a decidir si upgradear conviene.
Instalar Claude Code · paso 0
Si recién estás arrancando y todavía no tenés Claude Code corriendo en tu Mac, empezá por acá · Spec Kit no funciona sin Claude Code instalado primero.
Por dónde empezar si recién instalás Claude Code
Por dónde empezar si recién instalás Claude Code: (1) confirmá que tenés Claude Code corriendo en tu Mac · si no, la guía /community/instalar-claude-code te lleva paso a paso, (2) instalá uv y verificá tu Python 3.11+ — sin esto, specify-cli no arranca, (3) seguí el Camino A si ya sos dev, o el Camino B si no querés tocar la terminal vos mismo, (4) corré specify init mi-proyecto --integration claude en una carpeta limpia y entrá ahí con Claude Code, (5) usá los 4 prompts copy-paste en orden (constitution → specify → plan → implement) sobre un proyecto chico de prueba primero, antes de meterle algo importante.
Para quién no aplica esta página
Para quién no aplica esta página: usuarios sin Claude Code instalado (Spec Kit es un agnóstico de UI pero necesita un agente activo · si solo usás el chat web de claude.ai, esto no te corre). Usuarios de Windows sin WSL (uv y specify funcionan en Windows nativo pero los scripts del scaffold asumen bash · si no tenés WSL, vas a chocar con paths). Plan free sin posibilidad de instalar Python en tu máquina (universidades, computadoras del trabajo con permisos restringidos). Y si ya estás en mid-build de un proyecto avanzado donde reescribir specs cuesta más que terminar a mano · Spec Kit conviene en proyectos que arrancan, no en los que están a 80% de terminados.