Cómo trabajo con Claude

01

El problema es el consumo.

Casi nadie llena una ventana de contexto cuando interactúa con un chat para sacar adelante un proyecto suelto. Pero sí quema muchos tokens, mucho dinero y muchos recursos del planeta al hacerlo.

Ejemplo de proyecto suelto: tres PDFs de 110 páginas, un Excel de 800 filas, veinte turnos de trabajo y seis versiones del documento. Total: 133 366 tokens. En una ventana de un millón, eso es el 13%. Cabe siete veces.

El modelo relee la ventana completa en cada interacción. En esos veinte turnos procesó 2.5 millones de tokens para 133 mil de material único.

El tutorial que sigue existe para que en cada interacción el modelo tenga al alcance solo lo que está vigente. Para que tengas mejores resultados, gastes menos, y hagas cada vez proyectos más complejos.

02

El asesor, y tu nivel declarado

El asesor vive en las instrucciones del proyecto donde estás trabajando. Define la secuencia de etapas, el alcance, los briefs y la revisión, y decide si una etapa cumplió sus criterios de salida.

Cuando el proyecto es de software, el asesor además te da los prompts que le pasas a Claude Code. La metodología corre entre los dos: el proyecto sostiene el contexto y la dirección, Claude Code ejecuta. Cuando el proyecto es de otra cosa, no conectas Claude Code y el asesor se queda igual.

Lo primero que declaras es tu nivel

Antes de pedirle nada, le digo qué tan lejos llego en la habilidad que voy a delegar. En software uso una escala del 1 al 10:

Con ese número el asesor deja de explicarme lo que ya sé y deja de asumir lo que todavía no sé. Un 2 necesita que le expliquen qué es un repositorio antes de pedirle un commit. Un 8 necesita el brief y que lo dejen trabajar.

Mi nivel en [la habilidad que vas a delegar] es [N] de 10,
donde 1 es [el extremo de abajo] y 10 es [el extremo de
arriba]. Ajusta a eso el lenguaje que uses conmigo:
no me expliques lo que ya sé, y no des por sabido lo que
todavía no sé.

03

Las tres reglas

Estas tres sostienen el método. El resto de la página es cómo se operan.

04

Empieza aquí: los seis pasos

Así arranco un proyecto nuevo. El proyecto se llena con lo que salga del primer chat.

Arriba te acabo de contar mi proyecto: por qué existe, qué quiero
lograr, en qué estatus está, qué sé, qué no sé y con qué
herramientas cuento.

Vamos a trabajarlo con un flujo de chats por etapa. Tú eres mi
asesor: defines la secuencia de etapas, el alcance, los briefs y
la revisión, y decides si una etapa cumplió sus criterios de
salida. Yo decido el objetivo, las prioridades, los hechos y la
aprobación final. Cuando haya que escribir código, tú me das el
prompt y yo se lo paso a Claude Code.

Ajusta tu lenguaje a mi nivel de conocimiento tal como te lo
describí. Si algo de lo que dije quedó incompleto o ambiguo,
pregúntamelo antes de escribir nada.

Este chat es la etapa cero y tiene un solo objetivo: dejar el
proyecto armado. Entrégame, en este orden:

1. INSTRUCCIONES DEL PROYECTO
   Un texto que yo pueda pegar tal cual en el campo de
   instrucciones del proyecto. Debe incluir: qué es el proyecto,
   quién soy y cuál es mi nivel, cómo debes comportarte, el flujo
   de chats por etapa, la política de defaults reversibles, y qué
   debes verificar antes de dar una etapa por terminada.

2. LOS ARCHIVOS DE CONTEXTO
   La lista de archivos que necesita este proyecto, con el
   contenido inicial de cada uno ya escrito a partir de lo que te
   conté. Como mínimo: los hechos que son verdad, el brief con
   objetivo y audiencia, las reglas de trabajo, y el archivo de
   estado. Marca con [POR CONFIRMAR] todo lo que yo no te haya
   dicho. Este proyecto tiene una carpeta vacía conectada: cuando
   yo apruebe la lista, escribe los archivos ahí.

3. LO QUE FALTA
   La lista de lo que necesitas saber de mí y que todavía no te
   he dicho, ordenada por lo que más bloquea.

4. EL CONTRATO DEL CHAT 01
   Nombre numerado, objetivo principal, condiciones de entrada,
   entregables, criterios de salida, fuera de alcance y estado.

5. EL MENSAJE PARA ABRIR EL CHAT 01
   El texto exacto que debo pegar como primer mensaje allá.

Reglas para todo lo que sigue:

- No inventes hechos sobre mí, sobre el proyecto ni sobre su
  estado. Lo que no te dije va como [POR CONFIRMAR].
- Guíame de un paso significativo a la vez.
- Lleva el estado de cada chat como No iniciado, En curso,
  Bloqueado o Completo.
- No cruces a la siguiente etapa hasta que cada criterio de
  salida esté verificado con evidencia.
- Cuando un chat alcance su objetivo: dilo explícitamente, haz el
  handoff, nombra el siguiente chat y dame el mensaje exacto para
  pegar allá.

05

El contrato de cada chat

Cada chat es una etapa acotada. Al abrirlo se definen siete cosas, y ninguna es opcional.

• Nombre numerado. 03 · Revisión de producto. La numeración conserva el orden aunque la interfaz ordene por reciente. Los decimales sirven para etapas que aparecen después, sin renumerar la historia: 07.1, 07.2.
• Objetivo principal. Una frase con el resultado que este chat tiene que producir.
• Condiciones de entrada. Qué tiene que ser cierto antes de empezar.
• Entregables. Salidas concretas.
• Criterios de salida. Condiciones observables que prueban que terminó.
• Fuera de alcance. Trabajo que pertenece a etapas posteriores.
• Estado. Exactamente uno de cuatro.

Un chat que cumple el contrato

Así se ve la respuesta cuando el contrato quedó bien puesto.

Chat: 02 · Implementación de la v1
Estado: En curso

Objetivo
Que el formulario de alta corra en local con datos de prueba.

Condiciones de entrada
Repositorio creado y brief leído. Cumplidas.

Entregables
La ruta /alta funcionando y el script que carga los datos
de prueba.

Criterios de salida
- npm run dev levanta sin errores
- /alta guarda un registro y lo vuelve a leer al recargar
- npm run checks pasa en verde

Fuera de alcance
Diseño visual, deploy y cuentas de usuario.

Primer paso
Crea el repositorio y confírmame que npm run dev levanta.
No toques nada de diseño todavía.

El modelo de estado

Cuándo abrir un chat nuevo

Un chat termina cuando la tarea terminó. Abre uno nuevo cuando pase alguna de estas cosas:

• Los criterios de salida de esta etapa están verificados.
• La siguiente fase trabaja en otro modo: de revisar a producir, de producir a lanzar.
• Un conjunto de artefactos nuevo pasa al centro del trabajo.
• Hace falta un brief de implementación nuevo.

Si la tarea sigue abierta y la conversación ya está larga, usa /compact y sigue en el mismo chat. Compactar conserva el hilo y tira lo que ya no se usa. Un chat largo sigue siendo un buen chat mientras la etapa sea coherente.

Cómo se trabaja dentro de una etapa

Dentro de un chat, de un paso a la vez. Para cada acción con peso:

1. Di el objetivo inmediato.
2. Explica por qué va ahora.
3. Da la acción exacta.
4. Di cómo se ve el éxito.
5. Di qué no se debe tocar.
6. Pide solo la evidencia necesaria para verificar.
7. Verifica.
8. Continúa.

Ejemplo: «Objetivo: verificar el preview sin tocar producción. Abre la URL del preview. Revisa la portada en desktop. Revisa el layout en móvil. No hagas merge ni cambies DNS. Mándame capturas de la portada en los dos anchos. Éxito significa que el preview carga y la interacción principal funciona en los dos tamaños.» Eso es más confiable que una lista larga de instrucciones sueltas.

El handoff describe estado verificado

Un handoff dice qué es cierto ahora y cómo se comprobó. Un handoff no es un resumen.

06

Las compuertas de etapa

Una compuerta es la frontera entre dos chats. No se cruza hasta que los criterios de salida de la etapa actual están cumplidos. Eso convierte el avance del proyecto en una máquina de estados.

El ciclo completo

La secuencia exacta cambia por proyecto. La lógica de compuertas se queda igual.

Acciones que merecen una compuerta extra

Algunas acciones pueden dejar efectos caros o imposibles de revertir: deploys a producción, cambios de DNS, borrar ramas o infraestructura, migraciones de datos, servicios de paga, exponer datos privados, cambiar autenticación, tocar facturación, sobrescribir repositorios.

1. Documenta el estado actual antes de tocar nada.
2. Define el rollback.
3. Usa previews o ramas donde se pueda.
4. Cambia un sistema a la vez.
5. Verifica antes del siguiente cambio de riesgo.

Trabajo en paralelo

Dos frentes pueden correr al mismo tiempo cuando no se estorban: la implementación avanza mientras se preparan los assets visuales; la investigación de contenido avanza mientras se audita la infraestructura. Cada frente conserva su objetivo, sus entregables, sus criterios de salida y sus dependencias. Un frente paralelo que se vuelve la fase principal sin que nadie lo diga es el modo silencioso de perder el hilo.

07

La memoria del proyecto

Si todos los chats anteriores desaparecieran, ¿qué hay que saber para continuar bien?

Esa pregunta es el trabajo entero del archivo de estado. Un sistema puede tener la memoria correcta y aun así actuar mal si no sabe en qué punto está.

# Estado del proyecto

## Fase actual
## Chat actual
## Estado
No iniciado | En curso | Bloqueado | Completo

## Completado
## En curso
## Bloqueos
## Estado verificado
## Siguiente hito requerido
## Siguiente chat
## Condiciones para abrir el siguiente chat
## Decisiones abiertas
## No rehacer

«No rehacer» convierte decisiones cerradas en restricciones. Los modelos intentan ser útiles reconsiderando todo desde cero, y ahí es donde se les dice que no: no reinicies la discovery, no vuelvas a generar los assets aprobados, no reabras el posicionamiento, no metas la infraestructura que ya se descartó, no migres producción durante una etapa de revisión.

Cada archivo manda sobre un tipo de pregunta

Muchos archivos no sirven de nada si el modelo no sabe cuál manda para cada decisión. Esta es la tabla que uso.

Ante conflicto entre documentos, gana el de arriba. Y manda siempre tu última instrucción explícita. Cuando cambias de opinión, el cambio se escribe de vuelta en el archivo que corresponde. Un cambio que se queda como recuerdo suelto dentro de un chat se pierde en el siguiente. Eso es mantener el canon.

El set de archivos completo

proyecto/
├── AGENTS.md
├── context/
│   └── factual-master.md
└── docs/
    ├── product-brief.md
    ├── design-direction.md
    ├── project-status.md
    ├── deployment-runbook.md
    ├── briefs/
    ├── handoffs/
    └── changelog.md

No todos los proyectos necesitan todos los archivos. El principio es que el conocimiento durable vive en artefactos durables, y el razonamiento temporal vive en chats.

La versión mínima

Para un proyecto chico, la metodología se reduce a cuatro documentos: un brief, el archivo de estado, las reglas de trabajo, y el texto del handoff al final de cada chat. Y cada chat solo necesita objetivo, entregables, criterios de salida, fuera de alcance y estado. Eso captura casi todo el valor sin volverse administración.

08

Quién decide qué

Esta separación está escrita en el AGENTS.md de mi proyecto y evita los dos accidentes más caros: que el agente que escribe código redefina el producto, y que yo termine decidiendo detalles técnicos que no me toca decidir.

• El nivel 3 no reinicia la discovery y no redefine el producto. Pregunta solo ante bloqueos genuinos.
• El nivel 2 no reabre decisiones de producto ya cerradas.
• Tu instrucción más nueva supersede cualquier documento previo, y se escribe de vuelta en el archivo de estado.

El asesor y tu nivel declarado están explicados en la sección 02.

09

Delegar a Claude Code

Cuando el trabajo pasa a Claude Code, va con un brief explícito. El brief es un contrato: la dirección ya está aprobada, las decisiones técnicas reversibles quedan delegadas, la discovery no se reinicia, y solo se preguntan bloqueos reales.

Un brief fuerte contiene

• Objetivo.
• Archivos que son fuente de verdad.
• Estado actual del repositorio o del sistema.
• Alcance y exclusiones.
• Restricciones.
• Criterios de aceptación.
• Checks que hay que correr.
• El reporte de cierre que se espera.
• La política de bloqueos.

La plantilla completa del prompt está en las plantillas, junto con el formato del reporte de cierre.

Verifica antes de cruzar

La verificación va aparte del reporte. Cuando un agente reporta «completado», significa que terminó su tanda. La etapa se cierra cuando tú revisas el preview, abres los archivos generados, lees los resultados reales de los comandos, checas el estado del repositorio, pruebas los enlaces, revisas desktop y móvil, confirmas el estado de producción y compruebas que no se coló alcance prohibido.

El proyecto avanza con evidencia.

10

Antipatrones

Cada uno de estos me pasó. El método existe para prevenirlos.

• Chat interminable. Una sola conversación mezcla discovery, implementación, revisión, lanzamiento y mantenimiento.
• Discovery repetido. Cada agente nuevo pregunta lo que ya se respondió hace dos semanas.
• Amnesia de contexto. Las decisiones críticas viven solo en mensajes viejos.
• Cambio de fase prematuro. Existe un preview, así que el proyecto avanza antes de revisarlo.
• Sobreconsulta. El agente te pide elegir cada detalle técnico menor.
• Sobrealcance. El agente que escribe código redefine la estrategia de producto.
• Completado sin verificar. Se acepta un «listo» sin revisar el resultado real.
• Fuga de alcance. Entran features de fases posteriores.
• Riesgo apilado. Se cambian código, infraestructura, DNS y producción al mismo tiempo.
• Handoff perdido. Un chat nuevo arranca sin saber qué se completó, qué falta y qué no se debe rehacer.

11

Plantillas

Todo el método se opera con estos textos. El prompt fundacional está arriba, en el paso 3.

Mensaje para abrir un chat nuevo

Este chat continúa [PROYECTO].

Lee los archivos del proyecto y el archivo de estado actual antes
de aconsejarme nada.

Nombre del chat:
[NN · NOMBRE]

Objetivo principal:
[UNA FRASE]

Condiciones de entrada:
-

Entregables:
-

Criterios de salida:
-

Fuera de alcance:
-

La fase anterior completó:
-

Estado verificado actual:
-

Archivos creados o actualizados:
-

No rehacer:
-

Guíame de un paso significativo a la vez.

Lleva el registro de este chat como No iniciado, En curso,
Bloqueado o Completo.

Si los criterios de salida todavía no se cumplen, dímelo
explícitamente y señala qué falta.

Cuando se cumplan todos: dilo, haz el handoff, nombra el
siguiente chat y dame el mensaje exacto para pegar allá.

Handoff de cierre de etapa

# Handoff · [etapa], [fecha]

## Completado en este chat
## Fase actual del proyecto
## Hechos y estado verificados
## Archivos creados o actualizados
## Decisiones tomadas
## Asuntos abiertos
## Bloqueos
## Objetivo del siguiente chat
## Primera acción en el siguiente chat
## No rehacer
## Lo que ya se rompió una vez
## Mensaje exacto para pegar en el chat siguiente

La penúltima sección guarda lo que ya falló una vez en el proyecto, escrito con su causa, para que el siguiente chat no lo repita. Cada línea costó una tarde. Escribirla cuesta un minuto.

Cierre explícito de una etapa

Este chat alcanzó su objetivo.

Completado:
-

Artefactos creados o actualizados:
-

Estado verificado:
-

La siguiente fase no continúa en este chat.

Abre un chat nuevo llamado:
[NN · NOMBRE DEL SIGUIENTE CHAT]

Pega esto como primer mensaje:
[HANDOFF]

Instrucciones del proyecto

El prompt fundacional te devuelve una versión hecha a la medida de tu proyecto. Esta es la base genérica, por si quieres compararla o escribirla tú.

Trabaja con un flujo de chats por etapa.

Cada chat del proyecto tiene un solo objetivo principal y define
explícitamente: nombre, condiciones de entrada, entregables,
criterios de salida, trabajo fuera de alcance, y estado
(No iniciado, En curso, Bloqueado, Completo).

No cambies de chat solo porque la conversación se hizo larga.
Quédate en el chat actual hasta que cada criterio de salida esté
verificado.

Mantén un archivo de estado persistente con: fase actual, chat
actual, trabajo completado, trabajo en curso, bloqueos, estado
verificado, siguiente hito, decisiones abiertas, condiciones para
abrir el siguiente chat, y qué no rehacer.

Guarda el conocimiento durable en archivos. Define fuentes de
verdad explícitas para hechos, dirección de producto, diseño,
reglas de implementación y procedimientos de operación.

Usa defaults reversibles y seguros para decisiones rutinarias.
Escala solo bloqueos genuinos: credenciales faltantes, requisitos
en conflicto, acciones destructivas, cargos económicos, riesgo de
seguridad o privacidad, riesgo en producción, o decisiones caras
de revertir.

Cuando delegues implementación a Claude Code, entrega un brief con
objetivo, archivos fuente, estado actual, alcance, exclusiones,
restricciones, criterios de aceptación, checks, política de
bloqueos y formato de reporte.

No aceptes automáticamente el "listo" de un agente como etapa
completa. Verifica el artefacto contra los criterios de salida.

Cuando un chat alcance su objetivo:
1. dilo explícitamente;
2. lista resultados y estado verificado;
3. haz un handoff estructurado;
4. nombra el siguiente chat;
5. dame el mensaje exacto para pegar allá;
6. di qué no debe rehacerse.

Si los criterios de salida no se cumplen, dime explícitamente que
me quede en este chat y qué falta.

Prompt para Claude Code

Proyecto: [NOMBRE].

ACCESO A CARPETAS
- Monta y trabaja SOLO en: [carpeta]/
- No accedas a ninguna carpeta fuera de ella.
- Escribe código únicamente dentro de: [carpeta]/web/
- Trata como SOLO LECTURA: [carpeta]/context/

LEE PRIMERO (en este orden)
- AGENTS.md
- docs/project-status.md
- docs/handoffs/[el más reciente].md
- [los archivos específicos de esta tanda]

OBJETIVO DE ESTA TANDA
- [una frase: qué debe quedar corriendo al terminar]

ALCANCE
- Haz: [lista corta]
- No hagas: [lista corta de exclusiones]

REGLA QUE NO SE ROMPE
- [la frontera del proyecto, con su prueba]

CHECKS ANTES DE REPORTAR
- [comandos con el resultado esperado]

REPORTE DE CIERRE (formato obligatorio)
- Completado / Archivos cambiados / Checks corridos con
  resultado real / Decisiones autónomas / Supuestos /
  Placeholders / Bloqueos / Próximo paso.

POLÍTICA DE BLOQUEOS
- Usa defaults reversibles y sigue. Escala solo: credenciales
  faltantes, requisitos en conflicto, acciones destructivas,
  cargos económicos, riesgo de seguridad o privacidad, o
  decisiones caras de revertir.

Reporte de cierre que le exiges al agente

### Completado
### Archivos cambiados
### Checks corridos      # comandos y resultados reales
### Decisiones autónomas # reversibles, sin consulta
### Supuestos
### Placeholders         # assets, links, copy, datos
### Bloqueos             # solo bloqueos genuinos
### Próximo paso         # acción exacta que te toca a ti

Para terminar

Lo que esto no hace por ti

Todo lo de esta página es infraestructura. Sirve para que el modelo tenga enfrente lo correcto en cada interacción. No sustituye la parte que sigue siendo tuya.

Mi objetivo con el proyecto del entrevistador es este reparto:

Ese veinte por ciento no se automatiza. Y tiene una condición incómoda: una corrección que no se anota se va a repetir. Lo comprobé con una muletilla del modelo que corregí en un chat, y que volvió a aparecer en el siguiente output porque la corrección se quedó en la conversación en vez de irse al archivo.

Una persona con criterio que no lo escribe obtiene exactamente lo mismo que una sin criterio.

El método existe por eso: para que tu criterio sobreviva al chat en el que lo dijiste.