Escribe un brief de contexto de Claude que nunca vuelvas a reescribir
5 min de lectura
La mayoría de las personas empieza cada chat nuevo de la misma manera: una o dos frases de contexto y luego la petición de verdad. Tu puesto, tu equipo, en qué trabajas este trimestre, todo reescrito de memoria, un poco distinto cada vez. Funciona, pero es el mismo costo de configuración pagado una y otra vez por información que en realidad no ha cambiado.
Consejo
Un brief de contexto no es un prompt más largo. Es el puñado de datos que son ciertos sin importar lo que pidas ese día, escritos una vez para que dejes de decidir de nuevo cómo redactarlos.
Si reescribes las mismas tres frases cada semana, pertenecen a un brief, no a tu memoria.
Qué pertenece realmente a un brief
Un brief de contexto es corto a propósito. Contiene los datos que siguen siendo ciertos en muchas peticiones distintas, no los detalles específicos de la tarea de hoy. Mezclar ambas cosas es lo que hace que la gente abandone la idea después de un intento, ya que un brief que intenta cubrirlo todo da tanto trabajo mantener como reescribir.
Tu puesto y tu equipo, con la especificidad suficiente para importar
Términos estándar o jerga que tu trabajo usa y que Claude no conocería de otro modo
Prioridades actuales o contexto que dan forma a cómo quieres que se aborde la mayoría de las cosas en este momento
Lo que no pertenece: cualquier cosa específica de una tarea. La fecha límite de este correo en particular, el público de esta diapositiva en particular, el número exacto de este reporte en particular. Ese detalle cambia cada vez, así que pertenece al prompt mismo, no a un brief que tendrías que editar constantemente para mantenerlo exacto.
Un error común es escribir algo más cercano a una biografía completa del equipo que a un brief: el nombre de cada subordinado directo, cada proyecto pasado, cada herramienta que el equipo haya usado. Nada de eso cambia cómo debe Claude abordar una petición típica tuya, así que nada de eso merece un lugar en algo que debe mantenerse lo bastante corto para reutilizarse de verdad. Si un dato no cambiaría cómo maneja Claude la mayoría de tus peticiones, pertenece a un documento en otro lado, no aquí.
Este es mi contexto: soy líder de operaciones en una empresa de logística de 40 personas. Mi equipo se encarga de las relaciones con proveedores y la documentación de procesos internos. Usamos “SOP” para procedimiento operativo estándar y “el empujón del T3” para referirnos a nuestro proyecto actual de consolidación de almacén. Ten esto presente durante el resto de esta conversación.
”Fíjate en lo que falta en ese brief: ninguna mención de la tarea específica de hoy. Esa viene después, en la petición real, una vez establecido el contexto.
Dónde vive realmente un brief
Para una necesidad aislada, pegar el brief al inicio de un chat basta. Te cuesta un pegado en lugar de fragmentos dispersos en diez frases sueltas, y Claude lo tiene durante el resto de esa conversación.
Para un trabajo que abarca muchos chats durante semanas o meses, reescribir el mismo brief al inicio de cada chat nuevo anula el propósito. Es exactamente el hueco que cierra un Proyecto: guarda el brief una vez como instrucciones permanentes de un Proyecto, y cada chat que inicies dentro de él ya tiene ese contexto, sin nada que pegar. Si todavía no has configurado uno, el artículo sobre trabajar con Proyectos en esta ruta explica exactamente cuándo vale la pena.
La línea divisoria es la frecuencia, no la importancia. Un brief para una sola presentación de mucha importancia solo necesita pegarse una vez, al inicio de ese chat. Un brief para un puesto continuo, que de otro modo reescribirías decenas de veces en un trimestre, es lo que realmente justifica el costo de configuración de un Proyecto.
Dentro de Claude Tutorial
Escribir algo una vez para dejar de repetirlo es un hábito transferible.
Un brief de contexto reutilizable es una versión de un patrón que aparece en todas partes: escribe la parte estable una vez, reutilízala y solo toca la parte que de verdad cambia. La app tiene una lección completa sobre este hábito, con práctica que se lleva mucho más allá de escribir un brief.
Probarlo y actualizarlo cuando queda obsoleto
Un brief que escribes una vez y nunca revisas se aleja poco a poco de la realidad. Tu equipo cambia, un proyecto termina, la jerga que usabas hace seis meses deja de significar algo para cualquiera, incluido tú. Trata un brief como un documento vivo, no como una tarea de configuración de una sola vez.
- 1
Escribe una primera versión corta
De tres a cinco frases. Si es más larga, se está desviando a detalles específicos de tareas que pertenecen más bien a prompts individuales.
- 2
Pruébala con una petición real
Pega el brief y luego pide algo que pedirías de todos modos. Revisa si la respuesta de verdad refleja el contexto, no solo si Claude confirmó haberlo leído.
- 3
Revisa lo que no caló
Si un término no se captó bien, o una prioridad no dio forma a la respuesta como esperabas, reescribe esa sola línea en lugar de todo el brief.
- 4
Revísalo cuando cambie algo real
Un puesto nuevo, un proyecto terminado, una jerga que ya nadie usa. Toma eso como el detonante para actualizarlo, no un calendario fijo.
Con base en el contexto que te di arriba, ¿algo de mi puesto o del empujón del T3 parece desactualizado o incompleto de una manera que cambiaría cómo abordarías una petición típica mía? Pregúntame directamente si algo no está claro.
”Un brief que de verdad funciona se desvanece en el fondo. Dejas de notar que lo usas, y ese es todo el punto: el costo de configuración solo tenía que pagarse una vez.
Sigue leyendo
- Trabajar con Proyectos: darle a Claude un contexto que se queda: dónde pertenece un brief como este cuando tu trabajo abarca más de un puñado de chats.
- Cómo empezar con Claude: el hábito anterior de mantener un conjunto corto de instrucciones reutilizables, que este artículo convierte en algo más duradero.