Cómo organizar un proyecto en Claude Cowork

En este artículo quiero compartir como estoy organizando mis proyectos en Claude. Es un contenido dinámico que voy actualizando conforme descubro nuevas funciones y creo estructuras que mejoran mi rendimiento. Espero que os sea de utilidad.

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 de context/ evita que el modelo gaste contexto «entendiéndolos» cuando en realidad solo hay que procesarlos.
• output/ (o entregables/) — Lo que el modelo produce: borradores, documentos generados, planes. Mantenerlos fuera de context/ evita que mañana lea sus propios borradores viejos como si fueran briefing del proyecto.
• scripts/ (o code/) — 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.png

El 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.

Cuando varios proyectos necesitan los mismos datos

Claude no tiene proyectos anidados. No puedes crear un proyecto «Auditour» y colgar de él un subproyecto de seguridad, otro de desarrollo y otro editorial: cada proyecto es una isla con su carpeta y su CLAUDE.md. El problema aparece en cuanto varios de esos proyectos necesitan la misma información de partida.

Es mi caso. Gestiono una flota de 88 webs, propias y de clientes, y los datos de esa flota —quién es el titular, en qué hosting está cada una, qué convención de .htaccess sigue, qué política de robots tiene— los necesitan al menos cuatro proyectos distintos. La salida fácil es duplicar el documento en cada uno. Es también la peor: en cuanto actualizas una copia, las demás mienten. Y mienten con seguridad, que es la forma más cara de mentir cuando el que lee es un modelo que va a actuar sobre producción.

Lo que hago es lo contrario: un único proyecto propietario de esos datos, y esa misma carpeta conectada como carpeta adicional en todos los proyectos que la consumen. Cowork permite conectar más de una carpeta a un proyecto, y ahí está toda la palanca. No es un subproyecto, pero resuelve el problema que te haría desear subproyectos: compartir contexto sin duplicarlo.

El proyecto canónico

El proyecto se llama Auditour Fleet y su función es una sola: ser la única versión de la verdad sobre la flota. Sigue exactamente el patrón de raíz limpia del resto del artículo, con una carpeta específica para el detalle por sitio:

Auditour Fleet/
├── CLAUDE.md
├── context/          → aplica a TODA la flota, se lee siempre
│   ├── Flota Webs Auditour.md
│   ├── Convenciones de Configuración del Fleet.md
│   └── Política de Robots y Bots del Fleet.md
├── docs/             → manuales de herramientas propias, bajo demanda
├── data/
│   └── sitios/<dominio>/   → snapshot de configuración de UNA web
├── output/
└── archivo/

Dos detalles que marcan la diferencia. El primero: el censo de las 88 webs no se edita a mano, se regenera desde una consulta de Access. Un documento canónico que se puede tocar a mano deja de ser canónico el primer día que alguien tiene prisa. El segundo: el CLAUDE.md deja escrito que data/sitios/ no se carga nunca en bloque —primero se identifica el sitio en el censo y solo entonces se abre su carpeta—. Sin esa instrucción, una carpeta compartida que crece acaba quemando el contexto de todas las sesiones de todos los proyectos.

La regla que lo sostiene todo: solo lectura, en dos capas

Compartir una carpeta entre proyectos abre una puerta peligrosa: cualquier sesión de cualquier proyecto puede escribir en ella. Y un error escrito desde un proyecto consumidor se propaga al instante a todos los demás, sin más historial que el de Dropbox.

Por eso la regla es tajante: la carpeta compartida solo se lee. La única sesión autorizada a escribir es la que trabaja en el proyecto canónico. Si un proyecto consumidor detecta un dato obsoleto, no lo corrige: termina la tarea con el dato real que ha verificado y me lo reporta en el chat. La corrección la hago yo, desde donde toca.

Esa regla la escribo dos veces, y no por redundancia decorativa:

• En el CLAUDE.md de cada proyecto consumidor, como sección propia con el mapa de la carpeta compartida y el protocolo ante datos desactualizados.
• En la casilla «instructions» del proyecto, en versión corta. El CLAUDE.md es un archivo más de la carpeta y compite en atención con todo lo demás; las instrucciones del proyecto se inyectan en cada sesión y no se pueden dejar de leer. Para una regla de la que depende la integridad de la fuente canónica, una sola capa no basta.

Probé una tercera capa —marcar las carpetas como solo lectura en Windows— y la descarté: el atributo de solo lectura sobre una carpeta no impide escribir dentro, Dropbox tiende a resetearlo al sincronizar y estorba al propio proyecto canónico cada vez que toca actualizar. Con dos capas basta.

El alta en un proyecto consumidor

Dar de alta la carpeta en un proyecto nuevo son tres pasos, y los tengo documentados como procedimiento para no improvisarlos cada vez:

1. Conectar la carpeta raíz —no una subcarpeta— como carpeta adicional del proyecto. Se conecta la raíz porque es la que lleva el CLAUDE.md con las reglas. Hay que hacerlo en cada máquina por separado.
2. Pegar una vez el prompt de alta, que le pide al modelo que añada al CLAUDE.md local la sección de la carpeta compartida. Ojo aquí: con la carpeta conectada hay dos CLAUDE.md a la vista, y el prompt tiene que decir explícitamente cuál se toca y cuál no.
3. Copiar la regla de solo lectura en la casilla «instructions» del proyecto.

Y después, verificar: abro una sesión nueva y le pido un dato concreto de la carpeta compartida. Si lo devuelve bien y además declara que no escribe ahí, el alta está hecha.

Un aviso técnico por si a alguien se le ocurre el atajo: no uses enlaces simbólicos ni junctions para montar la carpeta en cada proyecto. Si origen y destino están dentro de Dropbox, el cliente los atraviesa como carpetas reales y sube una copia del material por cada proyecto que la monte, con el riesgo añadido de que una edición entre por la ruta espejo y genere conflictos con la canónica.

Qué va a la carpeta compartida y qué no

El criterio es el mismo que rige el resto del artículo, aplicado un nivel más arriba: ¿este dato lo necesita más de un proyecto y solo puede tener una versión? Si sí, es canónico y va a la carpeta compartida. Si es un análisis, un borrador o un entregable de un proyecto concreto, se queda en el output/ local de ese proyecto, por muy relacionado que esté con la flota.

Este patrón no es gratis y conviene saber qué se compra. No hay control de versiones real: el historial es el de Dropbox, y un borrado accidental se propaga a todos los proyectos antes de que te des cuenta. Tampoco hay permisos: la regla de solo lectura es una convención escrita, no un candado, y depende de que el modelo la respete y de que yo no la salte «solo esta vez». Y los archivos que guardo por sitio son snapshots fechados, no la configuración viva del servidor: antes de actuar en producción con uno de ellos, hay que verificarlo contra el servidor. Asumidas esas tres limitaciones, la alternativa —copias del mismo documento envejeciendo en cuatro proyectos distintos— es claramente peor.

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 de context/» 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.

Bonus track: Guía de Proyectos Cowork en formato md

Información que puede ser de utilidad.

1. El archivo SKILL.md de la habilidad:

   ---
   name: ab-estructura-proyecto
   description: Organiza y reorganiza la estructura de carpetas de un proyecto de Claude/Cowork según el patrón de raíz limpia (solo CLAUDE.md + subcarpetas) con context/, data/, output/, scripts/, assets/ y archivo/. Usa este skill SIEMPRE que el usuario quiera ordenar, reorganizar, limpiar o estructurar la carpeta de un proyecto, cuando diga que "la carpeta está desordenada", "hay demasiados archivos sueltos", "reorganiza las carpetas", "aplica mi estructura de proyecto", "ordena esto según mi metodología", "monta la estructura del proyecto nuevo", o cuando detectes archivos sueltos acumulados en la raíz de un proyecto aunque el usuario no lo pida explícitamente (en ese caso, avísale y ofrécelo). También aplica al crear un proyecto desde cero y al redactar o actualizar el CLAUDE.md con el mapa de carpetas. No usar para reorganizar repositorios de código ni estructuras de un CMS.
   ---
   
   # Estructura de proyecto: raíz limpia
   
   Metodología propia del usuario para organizar carpetas de proyectos en Claude.ai / Cowork sincronizadas vía Dropbox u otro servicio.
   
   ## Principio rector
   
   La raíz del proyecto contiene **solo `CLAUDE.md` y las subcarpetas**. Nada más.
   
   La raíz es el punto de entrada: lo primero que se mira al abrir el proyecto. Un archivo suelto ahí manda una señal ambigua sobre su función y puede leerse fuera de orden o interpretarse como instrucción.
   
   ## Criterio de clasificación
   
   Una sola pregunta por archivo: **¿quiero que esto influya en cómo Claude interpreta una tarea?**
   
   - Sí, es material de briefing → `context/`
   - No, es materia prima o resultado → la carpeta que corresponda por función
   
   | Carpeta | Contenido | Verbo |
   |---|---|---|
   | `context/` | Informes, guías, documentación de estado, briefings, instrucciones de referencia | Se **lee** para entender |
   | `data/` | Exports de Excel/CSV, ficheros crudos, datasets | Se **procesa con código** |
   | `output/` | Borradores, documentos generados, planes, entregables | Se **escribe** aquí |
   | `scripts/` | Snippets, hooks, funciones, código versionable | Se **ejecuta** o reutiliza |
   | `assets/` | Imágenes, logos, PDFs descargables, vídeos | Recursos binarios |
   | `archivo/` (o `_old/`) | Versiones antiguas que no se borran pero no deben mirarse | Se **ignora** |
   
   Ninguna es obligatoria. Un proyecto pequeño funciona con `context/` y `output/`. Las demás aparecen cuando el proyecto las necesita: **no crees carpetas vacías**.
   
   Caso clásico de error: un export de Google Search Console *parece* contexto, pero no se lee para entender nada — se abre con código para filtrar y segmentar. Va en `data/`.
   
   ## Convención de nombres
   
   - Documentos (`.md`, `.docx`, `.xlsx`, `.pdf`): **Title Case** con espacios y tildes normales. Ej.: `Informe Técnico del Sitio.md`.
   - Código (`.py`, `.js`, `.php`, `.html`, `.css`, `.sql`): **snake_case** o la convención del lenguaje.
   - Assets (imágenes, vídeo, audio): **snake_case sin tildes**. Ej.: `logo_nao_victoria.png`.
   
   ## Protocolo de ejecución
   
   ### Fase 1 — Inventario
   
   Recorre la carpeta del proyecto y lista todos los archivos con su ruta actual. No modifiques nada todavía.
   
   ### Fase 2 — Plan (requiere visto bueno)
   
   Presenta una tabla en Markdown:
   
   | Archivo actual | Destino propuesto | Motivo |
   |---|---|---|
   
   Reglas de esta fase:
   
   1. **No muevas nada sin aprobación explícita.** Mover archivos es irreversible en la práctica: rompe rutas y Dropbox propaga el cambio a todas las máquinas.
   2. **Regla de duda**: si un archivo no encaja con claridad en ninguna categoría, **déjalo donde está** y añádelo a una lista aparte titulada "Requiere criterio humano", con una nota de por qué es ambiguo. Es preferible eso a contaminar `context/` con entregables viejos.
   3. Señala también los renombrados necesarios para cumplir la convención de nombres, como columna o lista separada.
   4. Si detectas duplicados o versiones antiguas evidentes, propón `archivo/` — nunca borrado.
   
   Espera confirmación antes de continuar.
   
   ### Fase 3 — Ejecución
   
   Mueve y renombra según el plan aprobado. Nada más.
   
   ### Fase 4 — Actualización de referencias
   
   Obligatoria. Tras mover archivos, las rutas citadas en otros sitios quedan rotas. Revisa y reescribe:
   
   - Rutas mencionadas en `CLAUDE.md`
   - Rutas dentro de scripts (`scripts/`)
   - Rutas en documentos de `context/` que apunten a otros archivos del proyecto
   - Instrucciones del proyecto que nombren archivos concretos
   
   Lista al final qué referencias has actualizado.
   
   ### Fase 5 — Bloque de mapa en CLAUDE.md
   
   Crea o actualiza en `CLAUDE.md` un bloque con el mapa de carpetas y su *función*, no solo su existencia:
   
   ```markdown
   ## Mapa de carpetas
   
   - `context/` — leer para entender el proyecto antes de actuar
   - `data/` — procesar con código, no leer como briefing
   - `output/` — escribir aquí los entregables
   - `scripts/` — código versionable
   - `assets/` — recursos binarios
   - `archivo/` — versiones antiguas, no consultar
   
   Regla permanente: la raíz contiene solo CLAUDE.md y subcarpetas.
   Todo archivo nuevo se crea dentro de la carpeta que corresponda por función.
   ```
   
   Incluye solo las carpetas que existan realmente.
   
   Además, para archivos cuyo contenido es innegociable (instrucciones maestras, fuente única de datos), mantenlos como lectura explícita y nominal en `CLAUDE.md` (`Lee X`), separada del barrido genérico de `context/`. En carpetas grandes se tiende a muestrear en vez de leer entero; lo crítico se nombra a mano.
   
   ## Límite importante
   
   Este skill solo se activa cuando se invoca. **No impide que se vuelvan a generar archivos sueltos en la raíz en tareas posteriores.** La disciplina diaria de escritura vive en `CLAUDE.md` (Fase 5), no aquí. Si el usuario aplica este skill a un proyecto sin `CLAUDE.md`, avísale de que sin ese bloque el desorden reaparecerá y ofrécele crearlo.
   
   ## Salida
   
   Informe final breve en Markdown: movimientos ejecutados, renombrados, referencias actualizadas y lista de archivos que requieren criterio humano. Sin relleno explicativo.
   

2. El prompt que uso para reorganizar las carpetas de un proyecto de Claude Cowork ya existente:
   Vas a reorganizar la estructura de carpetas de este proyecto aplicando el skill ab-estructura-proyecto. Léelo antes de empezar y sigue su protocolo de cinco fases sin saltarte ninguna. Contexto: este proyecto lleva tiempo activo y ha acumulado archivos sueltos en la raíz. El objetivo es dejar la raíz con solo CLAUDE.md y las subcarpetas. Empieza por la Fase 1 (inventario) y la Fase 2 (plan). Preséntame la tabla archivo actual → destino propuesto → motivo, junto con la lista de renombrados necesarios y la lista de archivos que requieren criterio humano. NO muevas, renombres ni borres nada hasta que yo apruebe el plan explícitamente. Cuando lo apruebe, ejecuta las fases 3, 4 y 5, incluida la actualización de todas las rutas rotas y el bloque de mapa de carpetas en CLAUDE.md. Si este proyecto no tiene CLAUDE.md, dímelo antes de nada.
3. Guía Organización de Proyectos en Claude