Las 3 cosas que siempre hago antes de trabajar con Claude Code
El ritual de 3 pasos que aplico antes de pedirle una sola línea de código a Claude Code. Brainstorming para entender la idea, búsqueda de skills útiles, y plan mode con todo el contexto cargado. La diferencia entre un resultado mediocre y uno que da gusto leer.
La mayoría arranca con Claude Code igual: abre el chat, tira el pedido, y reza.
A veces sale. Muchas veces sale rápido y mal. Y después uno se pasa más tiempo arreglando que el que ganó arrancando.
Yo aprendí a la fuerza que el resultado de Claude Code se define antes de tipear el primer prompt de implementación. No después.
Estas son las 3 cosas que hago siempre, sin saltarme ninguna, antes de pedirle código.
1. Brainstorming con Claude para entender la idea y crear documentación
Antes de cualquier cosa, abro una conversación nueva y le hago una sola pregunta: ¿qué estoy tratando de construir, en serio?
No le pido código. Le pido que me ayude a pensar.
Prompt a usar
Quiero construir [idea en una línea].
Antes de escribir código, hacé brainstorming conmigo.
Hacé preguntas hasta entender:
- Qué problema resuelve
- Quién lo va a usar
- Casos de uso reales
- Qué NO entra en alcance
- Riesgos o supuestos que estoy haciendo
No propongas implementación todavía. Solo preguntas.
Una por una, esperá mi respuesta antes de seguir.
Resultado esperado
Una conversación de ida y vuelta donde la idea se aclara sola. Lo que parecía un feature termina siendo tres. Lo que parecía urgente termina siendo opcional.
Si tenés instalada la skill brainstorming de Superpowers, este paso se dispara solo cuando el agente detecta que vas a construir algo. Si no, forzalo con el prompt de arriba.
Cuando la idea está clara, le pido que escriba el resultado:
Convertí toda esta conversación en un documento corto
que viva en el repo. Guardalo en docs/<feature>.md.
Incluí: problema, usuarios, casos de uso, alcance,
fuera de alcance, supuestos. Nada más.
Ese archivo es el ancla. Cualquier prompt futuro lo va a referenciar.
2. Buscar skills que me ayuden en la creación
Claude Code tiene un ecosistema de skills enorme. Cada skill es un cerebro especializado que se activa cuando el agente detecta que la tarea encaja.
El problema: si no sabés qué skills hay disponibles, no las usás. Y si no las usás, estás pidiéndole a un generalista que haga trabajo de especialista.
Prompt a usar
Voy a construir [feature, según el doc de docs/<feature>.md].
Listame las skills disponibles que puedan aplicar a este trabajo.
Para cada una decime:
- Qué hace
- En qué parte del proceso entra
- Si la tengo instalada o si la tengo que agregar
No la uses todavía. Solo armá la lista.
Resultado esperado
Una tabla mental con las skills que van a entrar en juego: una para diseño, otra para tests, otra para revisión, otra para deploy. Cada una con su rol.
Si te falta alguna, instalala antes de seguir. Una skill bien elegida ahorra 10 prompts de corrección después.
Algunas que uso casi siempre, dependiendo del proyecto:
→ frontend-design — Para que las UIs no salgan con cara de Bootstrap 2014.
→ tdd / test-driven-development — Red, green, refactor. Sin atajos.
→ systematic-debugging — Cuando algo no funciona y no quiero adivinar.
→ dignified-python o nodejs-backend-patterns — Para que el código backend no parezca escrito en 2015.
→ verification-before-completion — Para que el agente no diga "listo" sin haber corrido los tests.
3. Plan mode con la documentación y las skills cargadas
Recién acá pido un plan. Nunca antes.
Plan mode es un modo de Claude Code donde el agente arma el plan completo de implementación sin tocar archivos. Vos lo leés, lo corregís, y recién después aprobás la ejecución.
La clave: el plan se genera con el doc del paso 1 y las skills del paso 2 ya cargadas. No desde cero.
Prompt a usar
Entrá en plan mode.
Contexto:
- Doc del feature: docs/<feature>.md
- Skills relevantes: [lista del paso 2]
Armá un plan de implementación detallado:
- Tasks ordenadas, chicas, independientes donde se pueda
- Archivos involucrados en cada task
- Tests que vas a escribir antes del código
- Dependencias entre tasks
- Checkpoints donde tengo que revisar antes de seguir
No escribas código. Solo el plan.
Resultado esperado
Un plan que un junior podría seguir. Y que vos podés leer en 5 minutos para detectar el error antes de que cueste una hora arreglarlo.
Acá es donde se gana o se pierde el proyecto. Un plan flojo termina en un PR confuso. Un plan firme termina en código que casi se escribe solo.
Cuando el plan está bien, recién ahí salgo de plan mode y dejo que ejecute.
Por qué este ritual cambia todo
La diferencia entre "le tiré el prompt y ver qué sale" y este ritual es brutal. No porque Claude escriba mejor código. Porque deja de adivinar.
Con los 3 pasos:
• El agente sabe qué estás construyendo (paso 1). • El agente sabe cómo construirlo según mejores prácticas (paso 2). • El agente sabe en qué orden y con qué checkpoints (paso 3).
Sin los 3 pasos: improvisación cara con cara de productividad.
Tardás 15 minutos extra antes de empezar. Te ahorrás horas de "che, ¿por qué hiciste esto así?" después.
La idea más importante
Claude Code no falla porque sea malo. Falla porque la mayoría lo trata como un autocompletado glorificado en vez de tratarlo como un ingeniero al que hay que briefear bien.
"Garbage in, garbage out" no es solo para datos. Es para prompts también.
Si vas a construir algo en serio con Claude Code, no te saltes el ritual. Brainstorming, skills, plan. En ese orden. Siempre.