Un Project: reglas en las instrucciones, documentos en el conocimiento

El equipo de marketing pega el manual de marca y las reglas de tono al principio de cada chat nuevo. A veces alguien se olvida, a veces pega una versión vieja, y cada redactor termina con un resultado distinto.

Cuando un equipo repite lo mismo en cada conversación, eso tiene que vivir en un proyecto (Project) de claude.ai, configurado una vez y compartido.

Dos lugares, dos funciones

Un Project tiene dos partes que conviene no mezclar:

	Qué va	Cómo lo usa Claude
Instrucciones del proyecto (project instructions)	Reglas de comportamiento que valen siempre: público, tono, formato, qué señalar, qué hacer si falta información	Se aplican a todos los chats del proyecto
Conocimiento del proyecto (project knowledge)	Documentos de consulta: el manual de marca, las políticas, los contratos modelo, los informes	Los consulta según lo que se pregunte

La diferencia importa por cómo se lee el conocimiento. Cuando el conocimiento cargado crece y se acerca al límite de lo que Claude puede leer de una vez, el proyecto pasa automáticamente a modo RAG (RAG mode): en lugar de leer todo, Claude busca y recupera solo las partes que parecen relevantes para cada pregunta. Eso le permite manejar mucho más material, pero tiene una consecuencia: una regla escondida en un archivo puede no recuperarse nunca.

Por eso, si un equipo de finanzas guardó sus reglas de formato en un archivo del conocimiento y Claude “a veces las ignora”, la solución es mover esas reglas a las instrucciones y dejar en el conocimiento solo los documentos de referencia.

Instrucciones que dan criterios

Las instrucciones del proyecto funcionan como instrucciones a nivel sistema (system-level instructions): el marco de todas las respuestas. Unas instrucciones efectivas dicen:

• para quién es la salida (“abogados del área comercial que revisan contratos de proveedores”);
• qué formato tiene (“una tabla con cláusula, riesgo y recomendación”);
• qué hay que señalar siempre (“topes de responsabilidad, renovación automática, jurisdicción”);
• qué hacer cuando falta información (“si falta un anexo, avisalo en vez de suponer su contenido”).

“Sé profesional y muy cuidadoso”, en mayúsculas o no, no da ningún criterio. Tampoco alcanza con cargar una docena de revisiones viejas como conocimiento y dejar las instrucciones vagas: los ejemplos ayudan, pero las reglas que valen siempre tienen que estar escritas.

Cómo armarlo paso a paso

1. Juntá lo que el equipo repite en cada chat.
2. Separá reglas (van a instrucciones) de material de consulta (va a conocimiento).
3. Escribí las instrucciones con los cuatro puntos de arriba.
4. Cargá solo la versión vigente de cada documento.
5. Compartí el proyecto con el equipo (en los planes Team y Enterprise), para que todos usen la misma configuración.

Las trampas típicas

• Seguir pegando el manual en cada conversación, aunque sea “al final para que lo lea último”.
• Pedirle a cada persona que guarde las reglas en sus preferencias personales: cada uno termina con una versión distinta.
• Un único chat larguísimo para todo el trimestre en lugar de un proyecto.
• Arreglar una regla ignorada renombrando el archivo con “IMPORTANTE” o partiéndolo en pedazos: sigue dependiendo de que se recupere.

En el examen

Si el escenario dice que un equipo repite instrucciones en cada chat, buscá la opción que crea un Project compartido con las reglas en las instrucciones y los documentos en el conocimiento. Si dice que Claude ignora reglas que están en un archivo cargado (pista: mucho material, modo RAG), la respuesta es moverlas a las instrucciones. Y si pregunta cómo mejorar instrucciones vagas, elegí la que define público, formato, qué señalar y qué hacer cuando falta información.