Índice de contenidos
Por qué la organización importa más que las instrucciones
Llevo trabajando con IA aplicada desde 2023, y si algo he aprendido al pasar de ChatGPT a Claude y luego a Cowork es que el rendimiento de un proyecto no depende solo de lo bien que escribas las instrucciones. Depende, sobre todo, de cómo organices los archivos. Un proyecto desordenado hace que el modelo lea cosas fuera de orden, confunda materia prima con briefing o interprete un borrador viejo como si fuera una directriz vigente.
En este artículo no voy a explicar qué es Claude ni qué es Cowork: doy por hecho que ya los usas. Me centro en una sola cosa, concreta y práctica: cómo estructurar la carpeta de un proyecto para que el modelo sepa qué leer, qué procesar y dónde escribir. El ejemplo recurrente será la gestión de una web, pero el patrón sirve para cualquier proyecto.
El principio: una raíz limpia
La regla de partida es simple: la raíz de la carpeta del proyecto contiene solo el archivo CLAUDE.md y las subcarpetas. Nada más.
El motivo es que la raíz es el punto de entrada, lo primero que Claude o Cowork miran. Si mezclas ahí archivos sueltos, ensucias ese punto de entrada y corres el riesgo de que se interpreten como instrucciones o se lean fuera de orden. Un archivo suelto en la raíz manda una señal ambigua sobre su función; el mismo archivo dentro de una carpeta con nombre claro deja de ser ambiguo.
Qué es el archivo CLAUDE.md
Es el archivo de instrucciones maestras del proyecto: el briefing permanente que define cómo debe comportarse el modelo en ese contexto. Cumple tres funciones:
- Arranque. Indica qué leer antes de empezar cualquier tarea y en qué orden.
- Reglas de actuación. Qué puede hacer con autonomía y qué requiere mi visto bueno: acciones irreversibles, publicación en producción, credenciales, DNS, borrados.
- Mapa. Explica la función de cada carpeta, para que el modelo sepa dónde buscar y dónde escribir.
Un matiz importante: CLAUDE.md no tiene que contener todo el conocimiento del proyecto. Ese conocimiento vive en la carpeta de contexto. CLAUDE.md es el índice y el reglamento, no la enciclopedia.
Las carpetas principales
El criterio para decidir dónde va cada archivo se reduce a una sola pregunta: ¿quiero que esto influya en cómo el modelo interpreta una tarea? Si la respuesta es sí, es material de briefing y va a context/. Si es no, es materia prima o resultado, y va a otra carpeta según su función.
A partir de ahí, estas son las carpetas habituales:
context/— Lo que el modelo debe leer para entender el proyecto antes de actuar. Material de referencia conceptual: informes, guías, documentación de estado, briefings. Se lee, no se procesa.data/— Materia prima que se procesa con código (Python, por ejemplo), no que se lee como briefing: exports de Excel, CSV, ficheros de datos crudos. Separarlos decontext/evita que el modelo gaste contexto «entendiéndolos» cuando en realidad solo hay que procesarlos.output/(oentregables/) — Lo que el modelo produce: borradores, documentos generados, planes. Mantenerlos fuera decontext/evita que mañana lea sus propios borradores viejos como si fueran briefing del proyecto.scripts/(ocode/) — Código que se versiona: snippets, hooks, funciones, fragmentos técnicos. Material que se ejecuta o se reutiliza, no que se lee para entender el proyecto.assets/— Recursos binarios: imágenes, logos, PDFs descargables, vídeos.archivo/(o_old/) — Versiones antiguas que no quieres borrar pero tampoco que el modelo mire. El prefijo_ayuda a que quede al final del listado.
No todas son obligatorias. Un proyecto pequeño funciona perfectamente con context/ y output/. Las demás aparecen cuando el proyecto las necesita.
Un ejemplo aplicado: la gestión de una web
Así es como queda la estructura para un proyecto de SEO y gestión de una web WordPress:
proyecto-web/
├── CLAUDE.md
├── context/
│ ├── Instrucciones del Proyecto.md
│ ├── Informe SEO.docx
│ ├── Informe Técnico del Sitio.md
│ └── Guías de Plugins.md
├── data/
│ ├── Export GSC.xlsx
│ ├── Keywords Semrush.xlsx
│ └── Especialidades y Prioridades.xlsx
├── output/
│ ├── Artículo Extinción de Condominio.html
│ └── Plan Editorial Mensual.md
├── scripts/
│ ├── schema_legalservice.php
│ └── parse_gsc.py
└── assets/
└── logo.pngEl export de GSC es el caso típico de archivo que parece contexto pero no lo es: no se lee para «entender» nada, se abre con código para filtrar y segmentar. Por eso va en data/ y no en context/. Esta distinción, que parece menor, es la que más rendimiento me ha dado en proyectos grandes.
Tres recomendaciones que aplico siempre
Más allá de la estructura, hay tres detalles que marcan la diferencia con el uso continuado:
- Documenta el mapa de carpetas dentro de
CLAUDE.md. Una línea basta:context/= leer,data/= procesar con código,output/= escribir aquí,scripts/= código. Así el modelo conoce el para qué de cada carpeta, no solo que existen. - Nombra a mano lo innegociable. Para los archivos cuyo contenido es crítico —las instrucciones maestras, una fuente única de datos— indícalos como lectura explícita y nominal en
CLAUDE.md(Lee X). Una instrucción genérica del tipo «revisa todos los archivos decontext/» es robusta ante renombrados, pero en carpetas grandes el modelo tiende a muestrear en vez de leer entero. Lo crítico se nombra a mano. - Sé consistente con los nombres. Title Case para documentos, snake_case para código. La coherencia ayuda tanto a ti como al modelo a navegar el proyecto sin ambigüedades.
Conclusión
Organizar un proyecto en Claude o Cowork no es una cuestión estética. Es lo que separa un asistente que entiende tu proyecto de uno que te devuelve respuestas genéricas porque ha leído los archivos equivocados en el orden equivocado. La raíz limpia, un CLAUDE.md que actúe de índice y reglamento, y una separación clara entre lo que se lee, lo que se procesa y lo que se produce: con eso tienes el 90% del trabajo hecho. El resto es ir afinando a medida que el proyecto crece.
