Un chat no es un sistema de trabajo.

Por qué la ventana de chat es la unidad de trabajo equivocada

Una conversación empieza en cero. Siempre. No sabe quién es tu cliente, cómo escribes, qué acordaste la semana pasada ni por qué descartaste la propuesta anterior. Tú eres la memoria del sistema, y eso significa que cada vez que abres una pestaña nueva pagas el mismo peaje: contar de nuevo el contexto entero antes de poder pedir nada útil.

El chat es una buena interfaz para una pregunta suelta. Es una unidad pésima para el trabajo que se repite, y el trabajo de un profesional independiente es casi todo trabajo que se repite. Auditorías con la misma estructura. Reportes mensuales con el mismo formato. Propuestas que cambian el nombre del cliente y el 30% del contenido. Correos de seguimiento que ya escribiste cuarenta veces. Si cada una de esas tareas nace de una conversación en blanco, estás reconstruyendo el mismo andamio todos los días.

Lo que sustituye al chat no es un prompt más largo. Son tres cosas que ya existen y que la mayoría de la gente no usa: Proyectos, que guardan contexto persistente y lo aplican a cada conversación dentro de ellos; archivos de contexto, que declaran una sola vez cómo trabajas; y Skills, carpetas con un archivo SKILL.md que Claude carga por su cuenta cuando la tarea lo amerita. Con eso, la conversación deja de ser el contenedor de tu trabajo y pasa a ser lo que debería haber sido siempre: la superficie donde ejecutas algo que ya está montado.

El impuesto de contexto es el gasto real

Cuando alguien calcula lo que le cuesta la IA, mira el precio de la suscripción o el precio por millón de tokens. Ninguno de los dos es el gasto grande. El gasto grande son los minutos que dedicas, todos los días, a explicar otra vez lo mismo: quién es el cliente, qué tono usa, qué no se puede decir, cuál es el objetivo del trimestre, cómo quieres el entregable. Cinco minutos de preámbulo por conversación, seis conversaciones al día, y ya llevas media hora diaria escribiendo un texto que es prácticamente idéntico al de ayer.

Ese impuesto se elimina escribiéndolo una vez. No en tu cabeza, no en una nota suelta: en un archivo, con estructura, que vive donde Claude lo va a leer.

El primero es el brief por cliente. Una página, no diez. Qué hace la empresa, a quién le vende, cómo habla y cómo no, quién decide, qué se probó antes y falló, qué métricas importan de verdad, qué está prohibido mencionar. La prueba de que está bien escrito es sencilla: si se lo pasas a un colaborador nuevo y puede redactar algo defendible sin llamarte, sirve. Si necesita llamarte, le falta contexto.

El segundo es un archivo operativo, el equivalente personal de un CLAUDE.md: cómo trabajas tú, no el cliente. Qué formato quieres en los entregables, qué te molesta de una respuesta genérica, qué nivel de detalle esperas, cuándo prefieres que te haga preguntas en lugar de asumir, qué palabras no usas nunca. Este archivo es aburrido de escribir y es el que más rinde, porque aplica a todos tus clientes a la vez.

El tercero es una Skill por tarea repetida. Una Skill es una carpeta con un SKILL.md dentro, y su mecánica importa: la descripción de la Skill está siempre presente, pero el archivo completo solo se lee cuando la tarea lo pide. A eso se le llama divulgación progresiva, y tiene una consecuencia práctica que casi nadie tiene en cuenta. La descripción no es una etiqueta decorativa, es el disparador. Escríbela como una condición de uso, no como un título. "Auditoría de una cuenta de anuncios" es un título. "Usar cuando haya que revisar una cuenta de Meta Ads o Google Ads y producir un diagnóstico con recomendaciones priorizadas" es un disparador.

Un Proyecto por cliente, no un Proyecto por herramienta

El error de organización más común es agrupar por tipo de tarea: un Proyecto para "redacción", otro para "análisis", otro para "correos". Se siente ordenado y es inservible, porque lo que cambia entre un encargo y otro no es el verbo, es el cliente. El contexto que necesitas para escribir un correo para Cliente A se parece mucho más al que necesitas para analizar sus datos que al que necesitas para escribir un correo para Cliente B.

Un Proyecto por cliente, con su brief dentro, y las Skills genéricas viviendo aparte porque son transversales. Añade un Proyecto más, el tuyo: tu propio negocio, tu prospección, tu contabilidad, tus propuestas. Es el que más vas a abandonar y el único cuyo cliente no te va a reclamar, así que ponle una revisión fija en el calendario.

Elegir el modelo por tarea, no por costumbre

Casi todo el mundo elige un modelo una vez y lo usa para todo durante meses. Es cómodo y es caro en los dos sentidos: pagas de más en las tareas triviales y te quedas corto en las difíciles. La decisión correcta se toma por tarea, y son cuatro opciones.

La regla práctica cabe en una frase: si la tarea se repite mucho y piensa poco, Haiku; si es tu trabajo normal, Sonnet; si el problema es duro, Opus; si Opus se atasca de verdad, Fable. Los tres modelos grandes tienen ventana de 1M de tokens, que en la práctica significa que puedes meter el histórico completo de un cliente en una sola sesión en lugar de trocearlo.

Qué se delega y qué no

Esta parte se cuenta mal casi siempre, y conviene ser honesto porque tu negocio depende de acertar. Delegas producción: primeros borradores, resúmenes de reuniones, extracción de datos de PDFs y capturas, comparación de versiones de un documento, traducción de un entregable, conversión de notas sueltas en una estructura, generación de las cinco variantes que después vas a descartar. Todo eso es volumen, y el volumen es exactamente donde un profesional independiente se ahoga.

No delegas tres cosas, y no por prudencia moral sino porque no funciona.

El criterio. Decidir que este cliente necesita reducir presupuesto en vez de aumentar alcance es una decisión que se toma con información que no está en ningún archivo: cómo respiró el director financiero en la última llamada, qué pasó en la empresa el año pasado, qué se puede defender internamente. Puedes usar a Claude para estructurar la decisión y para atacarla desde el lado contrario. La decisión sigue siendo tuya.

La relación. Tu cliente no te paga por documentos, te paga porque confía en ti. Un correo difícil, una mala noticia, una renegociación de alcance: escribe el borrador con ayuda si quieres, pero la conversación es tuya. El día que el cliente detecte que le está respondiendo un sistema, dejaste de ser un asesor y pasaste a ser un proveedor sustituible.

La responsabilidad final. Firmas tú. Si el número está mal, el error es tuyo. Esto tiene una consecuencia operativa concreta: todo dato, cifra, cita o afirmación legal que vaya a salir con tu nombre se verifica contra la fuente antes de enviarse. Sin excepciones y sin importar lo convincente que suene.

La primera semana, en orden

Cinco pasos, uno por día, cada uno con un resultado que se puede comprobar. Si no puedes comprobarlo, no lo has hecho.

1. Escribe tu archivo operativo. Una página sobre cómo trabajas tú: formato, tono, nivel de detalle, cuándo preguntar en vez de asumir. Comprobación: pides un entregable sin dar instrucciones de formato y sale con tu formato.
2. Crea un Proyecto para tu cliente principal y mete su brief. Comprobación: abres una conversación nueva dentro del Proyecto, pides un borrador y no tienes que explicar quién es el cliente ni una sola vez.
3. Convierte tu tarea más repetida en una Skill. Elige la que hiciste más veces el mes pasado. Escribe la descripción como condición de uso, no como título. Comprobación: en una conversación nueva describes el trabajo con tus palabras normales y la Skill se activa sola, sin que la nombres.
4. Asigna modelo a tus cinco tareas habituales. Escríbelo en el archivo operativo. Comprobación: puedes decir en voz alta qué modelo usas para cada una y por qué, sin dudar.
5. Conecta una sola fuente de datos. Una, la que más abres al día, vía MCP, el estándar abierto que conecta Claude con herramientas externas como Drive, GitHub o tu base de datos. Comprobación: haces una pregunta sobre un documento real y la respuesta sale sin que tú hayas copiado y pegado nada.

Cinco días, cinco resultados verificables. Ninguno requiere programar. Al final de la semana tienes algo que no tenías el lunes: un sistema que sobrevive a que cierres la pestaña.

Las tres formas de arruinarlo

Sobre-instruir. Es la primera y la más frecuente. La gente escribe prompts de setecientas palabras llenos de "actúa como un experto senior con veinte años de experiencia", instrucciones contradictorias y advertencias contra errores que el modelo no iba a cometer. El resultado empeora, porque instrucciones en conflicto producen respuestas tibias que intentan cumplir todo a la vez. Si tu prompt necesita setecientas palabras cada vez, eso no era un prompt: era contexto, y el contexto va en un archivo. Los prompts se acortan a medida que el sistema mejora, no al revés.

Confundir salida con trabajo terminado. Lo que sale es un borrador competente, no un entregable. La trampa es que ahora los borradores salen tan pulidos que parecen finales, y ese pulido apaga tu instinto de revisor. Mete un paso explícito entre generar y enviar: lees, verificas los datos, cortas lo que sobra, añades lo único que sabes tú y que no estaba en ningún archivo. Ese paso es el que estás cobrando.

Construir infraestructura para nada. Una Skill para algo que haces dos veces al año no ahorra tiempo, lo consume, y encima envejece: cuando llegue la segunda vez estará desactualizada y te fiarás de ella. El umbral honesto es la frecuencia semanal. Si no lo haces al menos una vez por semana, hazlo a mano y sigue con tu vida. Construir sistemas es mejor que acumular trucos, pero construir sistemas que nadie usa es solo otra forma de procrastinar con estilo.

La única métrica que importa

No es cuántas Skills tienes ni cuántos Proyectos abriste. Es cuánto tiempo pasa entre que recibes un encargo y entregas algo defendible, y si ese tiempo baja mes a mes. Si baja, el sistema funciona. Si no baja pero tienes doce Skills, construiste un museo. Empieza por lo más aburrido, mide el tiempo, y quédate solo con lo que se gana el espacio.