Cómo compartir con tu equipo el trabajo hecho con Claude

Ahora mismo, cuando un compañero te pide el hilo de Claude que usaste para redactar el brief de la campaña, probablemente copias y pegas el resultado final en Slack y lo das por terminado. Recibe la respuesta sin nada del razonamiento, así que la próxima vez que necesite ajustarla, abre un chat nuevo y reconstruye tu contexto desde cero.

Esa es la parte que vale la pena arreglar. El resultado no es lo valioso de lo que entregas. El contexto sí.

Lo más útil que puedes compartir no es la respuesta de Claude. Es todo lo que llevó a Claude a esa respuesta.

Cuándo compartir el trabajo hecho con Claude (y cuándo no)

No toda conversación con Claude merece un compañero. Compartir tiene un costo: alguien tiene que leer tu contexto, entender tu planteamiento y decidir si confía en tu configuración antes de poder construir sobre ella. Eso solo vale la pena cuando el trabajo va a algún lado.

Comparte cuando:

• El resultado será revisado por más de una persona con el tiempo (un documento de posicionamiento, la estructura de un informe, un brief de campaña).
• Varios miembros del equipo necesitan producir variaciones del mismo trabajo base (distintos públicos, distintos formatos, la misma investigación de fondo).
• Estás construyendo algo que durará más que la tarea actual, como una guía de estilo, un resumen de investigación o una plantilla de informe recurrente.

No te molestes en compartir cuando:

• La tarea es puntual y desechable, como reescribir un solo correo o resumir un artículo.
• Todavía estás en la fase desordenada y exploratoria y la conversación está llena de callejones sin salida. Límpiala primero, o nadie podrá saber qué importó.
• El compañero llegaría a la misma respuesta más rápido simplemente haciéndole la pregunta a Claude él mismo, con su propio contexto.

Una buena regla: si te tomarías la molestia de escribir un párrafo en Slack explicando “esto es lo que hice y por qué”, el trabajo es compartible. Si no te la tomarías, probablemente aún no está lo bastante terminado para entregarse.

Armar un Proyecto compartido que tu equipo realmente pueda usar

Un Proyecto de Claude es el contenedor correcto cuando el trabajo es continuo, pero solo si lo armas de modo que un colega pueda llegar en frío y empezar a contribuir. Eso significa hacer algo de trabajo estructural por adelantado en lugar de dejarlo como un montón de historial de chat.

1. Ponle al Proyecto el nombre de su propósito, no de su origen. “Brief de campaña T3” gana a “Chat de marketing 4”. Alguien debería saber para qué sirve antes de abrirlo.
2. Agrega primero un documento de contexto fijado. Antes de cualquier conversación, pon un brief corto en la base de conocimiento del Proyecto: para qué sirve, quién lo usa, cómo se ve el “terminado”.
3. Incluye el material fuente, no resúmenes del material fuente. Si el Proyecto trata de un lanzamiento de producto, agrega la especificación real del producto, no tu paráfrasis de tres oraciones. Los compañeros necesitan verificar afirmaciones, no solo confiar en tu lectura.
4. Fija expectativas sobre cómo debe usarse. Una nota de una línea como “Abre chats nuevos dentro de este Proyecto para cada borrador, no sobrescribas el brief fijado” ahorra confusión después.
5. Pruébalo tú mismo como un extraño. Abre el Proyecto de cero y pregunta: ¿alguien sin recuerdo de esta tarea podría averiguar qué hacer a continuación? Si no, agrega lo que falte.

Este armado es la misma razón por la que los Proyectos funcionan bien para un contexto que necesita persistir: el contexto vive en el propio Proyecto, no en la cabeza de una persona ni en el historial de desplazamiento de una conversación.

Compartir una conversación o un Proyecto: qué contenedor usar

Resuelven problemas distintos, y elegir el equivocado es una fuente común de fricción.

Comparte una sola conversación cuando:

• Es una entrega puntual. Alguien necesita ver cómo llegaste a una decisión y luego seguir adelante.
• La tarea tiene un final claro y nadie necesitará volver a este contexto el mes que viene.
• Quieres preservar una línea de razonamiento específica exactamente como ocurrió, sin que nadie más agregue hilos nuevos que la enturbien.

Arma un Proyecto cuando:

• Más de una persona contribuirá durante varias sesiones.
• El contexto (voz de marca, documentos fuente, decisiones previas) necesita ser reutilizable para muchas peticiones distintas, no solo una.
• Esperas que el trabajo evolucione. Una sola conversación se vuelve inmanejable rápido cuando varias personas echan preguntas sin relación en el mismo hilo.

Si dudas cuál aplica, pregunta si esto es una instantánea o un espacio de trabajo. Una instantánea es un momento en el tiempo que vale la pena preservar. Un espacio de trabajo es un lugar al que la gente seguirá regresando. Es la misma distinción que se trata en elegir entre un chat nuevo, un Proyecto o retomar un hilo viejo, solo que aplicada a nivel de equipo en lugar de individual.

Escribir un contexto que tu equipo pueda retomar y usar

El mayor fracaso individual en los flujos de equipo con Claude es entregarle un Proyecto a alguien y esperar que haga ingeniería inversa de tu razonamiento a partir del historial de chat en bruto. Escribe el contexto en su lugar. Toma cinco minutos y le ahorra una hora a todos los demás.

Una buena nota de entrega responde tres preguntas:

• ¿Qué he intentado ya? Incluye los enfoques que no funcionaron, no solo los que sí. Eso evita que un compañero vuelva a probar un callejón sin salida.
• ¿Qué está funcionando realmente ahora? Señala el borrador, decisión o resultado específico que debe tratarse como la base actual.
• ¿Cuál es el siguiente paso? No hagas que alguien adivine si debe refinar, ampliar o empezar una dirección totalmente nueva.

Aquí hay un formato que funciona bien fijado en la parte superior de un Proyecto compartido:

Prompt para la nota de entrega:

Resume esta conversación para un compañero que retoma este
trabajo desde cero. Incluye:
1. El objetivo original en una oración.
2. Qué enfoques se intentaron y descartaron, con una línea de
   razón para cada uno.
3. El mejor borrador o respuesta actual, citado completo.
4. El siguiente paso específico, formulado como tarea (por ejemplo,
   “aprieta el segundo párrafo” y no “sigue mejorándolo”).
Mantenlo en menos de 200 palabras. No incluyas cortesías ni salvedades.

Esto produce una nota que un compañero lee en treinta segundos en lugar de desplazarse por cuarenta mensajes. Para una versión reutilizable de esta misma idea, mira armar una ficha de contexto que dejes de reescribir, que cubre el formato con más profundidad.

Manejar la retroalimentación cuando tu equipo refina el resultado de Claude

En cuanto un compañero edita a mano un borrador de Claude, esa edición es la pieza de contexto más valiosa de todo el flujo, y es fácil perderla en el momento en que regresas a Claude para seguir iterando.

La solución es tratar las ediciones humanas como insumo, no solo como un producto terminado que reemplazará el siguiente borrador.

1. Registra la diferencia, no solo la versión final. Antes de pegar de vuelta en Claude el borrador revisado de un compañero, anota qué cambió y por qué, aunque sea brevemente (“quité el segundo párrafo, apreté la llamada a la acción, hice el tono menos formal”).
2. Devuelve el razonamiento al prompt, no solo el texto nuevo. Pídele a Claude que continúe en la dirección de la edición, no que la acepte simplemente como nueva materia prima.
3. Actualiza el contexto fijado si la edición refleja una preferencia permanente. Si tu compañero siempre quita adjetivos, esa es una regla de estilo que conviene agregar al brief del Proyecto, no algo que redescubrir en cada ronda.
4. Confirma que el siguiente borrador respete la edición antes de avanzar. Una revisión rápida como “¿esto mantiene la llamada a la acción más apretada de la última ronda?” detecta regresiones a tiempo.

Un prompt útil para esta entrega:

Aquí están el borrador anterior y la versión editada que mi
compañero devolvió. Compáralos y dime, en una lista corta, qué
cambió y por qué crees que se hizo cada cambio. Luego sigue
redactando la siguiente sección de forma consistente con esos
cambios, no con el borrador original.

[pega el borrador original]
[pega el borrador editado]

Esto mantiene el criterio de todo el equipo acumulándose en la misma dirección en lugar de reiniciarse cada vez que el trabajo cambia de manos. Es la misma lógica de remodelar un informe financiero para el consejo y para el equipo: un borrador de fondo, refinado y reformateado para distintos lectores, sin empezar de cero cada vez.

Trampas comunes de la colaboración y cómo evitarlas

Tres patrones explican la mayor parte de la fricción en los flujos de equipo con Claude. Cada uno tiene un momento reconocible en el que puedes atraparlo antes de que cueste tiempo real.

• La entrega silenciosa. Compartes el enlace de un Proyecto o conversación sin ninguna nota, suponiendo que la persona “solo lo revisará”. Ojo en el momento en que vayas a pegar un enlace en Slack sin contexto. Agrega dos oraciones antes de enviar.
• La deriva de contexto. La persona A refina el brief, la persona B trabaja desde una versión vieja en caché porque tenía una pestaña abierta desde ayer. Se nota como dos personas produciendo resultados contradictorios que suenan igual de seguros. La solución es hacer del documento de contexto fijado la única fuente de verdad y tratar cualquier copia fuera del Proyecto como temporal.
• Tratar un Proyecto como un chat grupal. Alguien empieza a echar preguntas sin relación en el Proyecto compartido (“por cierto, ¿me ayudas a escribir este otro correo?”) y el contexto se diluye con hilos fuera de tema. Ojo con un Proyecto que acumula conversaciones sin relación clara con su propósito declarado. Cuando eso pasa, es hora de abrir un chat nuevo en otro lugar, o un segundo Proyecto.

Ninguno de estos es un problema de Claude. Son problemas de coordinación que casualmente afloran dentro de Claude. La solución en cada caso es la misma: hacer explícito el contexto, mantenerlo en un solo lugar y decir en voz alta cuál es el siguiente paso en lugar de suponer que es obvio.

Sigue leyendo

• Trabajar con Proyectos: contexto que permanece para una mirada más profunda a cómo los Proyectos retienen el contexto entre sesiones, que es la base de la que depende todo este proceso.
• Armar una ficha de contexto reutilizable que dejes de reescribir si quieres un formato de notas de entrega que funcione más allá de compartir en equipo.
• Convertir una meta de campaña en un brief de una página como ejemplo concreto del tipo de resultado colaborativo que este proceso está hecho para respaldar.