Claude Cowork para founders y vibe coders: la guía de flujos de trabajo que nadie te dio en el onboarding
La mayoría de la gente usa Claude Cowork como un chatbot más rápido. Por eso les decepciona.
Cowork fuera de la caja es mediocre. Cowork bien configurado es una herramienta completamente diferente. La brecha entre los dos es aproximadamente 30 minutos de setup inicial — y este artículo es ese setup.
Si eres founder independiente, vibe coder construyendo SaaS, o builder que prefiere delegar el trabajo operativo para concentrarse en lo que importa, esta guía está escrita para ti. No para equipos enterprise con presupuestos de procurement. Para las personas que abren Cowork a las 9 AM y quieren que la mayor cantidad posible de trabajo operativo ya esté hecho cuando lleguen.
Primero: qué es Cowork por dentro (y por qué importa entenderlo)
Antes de los workflows, hay tres hechos técnicos sobre cómo funciona Cowork que definen todo lo que puedes hacer con él.
Hecho 1: Cowork corre en una VM Linux aislada en tu computadora. Los archivos se montan en la VM desde las carpetas que tú explícitamente le das acceso. Nada fuera de esas carpetas es visible para Cowork. La inferencia del modelo ocurre en la nube de Anthropic, así que necesitas conexión a internet en cada sesión. Esto importa para tu arquitectura de datos: lo que Cowork puede ver y tocar es exactamente lo que tú decidas que puede ver y tocar — ni más, ni menos.
Hecho 2: Cowork no tiene memoria entre sesiones. Cada conversación empieza desde cero. No sabe quién eres, qué haces, ni cómo te gustan las cosas — a menos que se lo digas explícitamente. La mayoría de la gente que abandona Cowork lo abandona aquí: porque cada vez que lo abren tienen que re-explicar el contexto. La solución no son mejores prompts. Son archivos de contexto que cargan automáticamente.
Hecho 3: La arquitectura es la misma que Claude Code. Cowork es Claude Code empaquetado en una GUI de escritorio sin necesidad de línea de comandos. Eso significa que tiene las mismas capacidades de razonamiento y ejecución que los developers usan desde la terminal — incluyendo sub-agentes que corren en paralelo, ejecución de código, y manipulación de archivos del sistema.
Con esos tres hechos claros, el setup tiene sentido.
El setup de 30 minutos que cambia todo
Paso 1: La estructura de carpetas (5 minutos)
La arquitectura de carpetas más efectiva para founders y vibe coders que han reportado sus workflows públicamente sigue este patrón:
/Cowork-Base/
├── Context.md ← quién eres y cómo trabajas
├── Skills.md ← automatizaciones predefinidas que puedes invocar
├── Projects/ ← una subcarpeta por proyecto activo
│ ├── SaaS-X/
│ ├── Cliente-Y/
│ └── Proyecto-Z/
├── Inbox/ ← donde dejas archivos para que Cowork procese
└── Outputs/ ← donde Cowork deposita los entregables terminados
La carpeta Inbox/Outputs es el patrón más reportado entre founders que usan Cowork productivamente: en lugar de interactuar con Cowork en tiempo real para cada tarea, dejan archivos en Inbox con instrucciones mínimas, y Cowork deposita los resultados en Outputs. Es la diferencia entre tener un asistente que espera instrucciones y uno que procesa trabajo mientras tú haces otra cosa.
Paso 2: El archivo Context.md (10 minutos)
Este es el archivo más importante del setup. Es el briefing que le das a Cowork al principio de cada sesión, automáticamente, sin que tengas que repetírselo.
Un Context.md efectivo tiene cinco secciones:
# Quién soy
Soy [tu nombre], founder de [nombre del proyecto].
[Descripción de una línea de lo que construyes].
Mi stack: [Next.js / Supabase / TypeScript / Vercel o lo que uses].
# Mis proyectos activos
- [Proyecto A]: [descripción en una línea, estado actual]
- [Proyecto B]: [descripción en una línea, estado actual]
# Cómo trabajo
- Idioma preferido para outputs: español
- Formato preferido para documentos: Markdown
- Tono para comunicaciones externas: [profesional / casual / técnico]
- Convenciones de código: [TypeScript estricto / camelCase / etc.]
# Restricciones importantes
- No modificar archivos en /producción sin confirmación explícita
- No commitear a main directamente
- Siempre crear backup antes de editar archivos existentes
# Contexto de negocio
[2-3 oraciones sobre tu mercado, tu audiencia, y tu diferenciador]
El tiempo que inviertes en escribir Context.md bien la primera vez se recupera en la primera semana. Cada sesión de Cowork empieza con este contexto ya cargado — lo que elimina la fricción de re-explicar quién eres cada vez.
Paso 3: Las instrucciones globales (5 minutos)
Las instrucciones globales son diferentes del Context.md: se configuran en Settings > Global Instructions y aplican a todas las sesiones, no solo al proyecto activo.
Las instrucciones globales más útiles para founders y vibe coders:
Siempre confirma antes de eliminar archivos, incluso si te lo pido explícitamente.
Cuando termines una tarea, lista los archivos que creaste o modificaste.
Si una tarea requiere más de 20 pasos, muéstrame el plan antes de ejecutar.
Para código, siempre incluye comentarios en español.
Cuando encuentres ambigüedad en una instrucción, pregunta antes de asumir.
Paso 4: Los conectores (5 minutos)
Los conectores dan a Cowork acceso en tiempo real a tus herramientas externas. La secuencia recomendada:
- Google Workspace (Drive, Gmail, Calendar) — si vives en el ecosistema Google
- Microsoft 365 (Outlook, OneDrive, SharePoint, Teams) — si vives en el ecosistema Microsoft
- Slack — si tu comunicación de equipo vive ahí
- GitHub — crítico para vibe coders y founders técnicos
Nota importante actualizada a julio 2026: Trello, Monday.com, ClickUp y Asana no tienen conectores oficiales. Puedes conectarlos via servidores MCP personalizados, pero requiere trabajo de setup adicional.
Paso 5: El archivo Skills.md (10 minutos)
Las Skills son automatizaciones predefinidas que puedes invocar con una línea. En lugar de escribir el prompt completo cada vez, defines la skill una vez y la llamas por nombre.
# Mis Skills
## brief-semanal
Genera el resumen semanal del proyecto [PROYECTO] con:
- Progreso vs. objetivos de la semana
- Blockers identificados
- Próximos 3 pasos prioritarios
- Métricas clave del período
Formato: Markdown, máximo 500 palabras.
## review-pr
Revisa el PR en [RUTA] y genera:
- Resumen de cambios en lenguaje no técnico
- Posibles issues de seguridad o performance
- Checklist de revisión completado
- Recomendación: aprobado / necesita cambios / rechazar
## email-cliente
Redacta un email para [CLIENTE] sobre [TEMA] con:
- Tono: profesional pero cercano
- Longitud: máximo 150 palabras
- CTA claro al final
- Sin jerga técnica
## análisis-competidor
Analiza [COMPETIDOR] y genera:
- Positioning vs. mi producto
- Features que tienen y yo no
- Features que yo tengo y ellos no
- Oportunidad de diferenciación
Los flujos de trabajo por perfil
Para el founder de SaaS en etapa temprana
El problema más común del founder early-stage no es falta de ideas — es que el trabajo operativo consume el tiempo que debería ir a producto. Estos tres flujos de trabajo atacan ese problema directamente.
Flujo 1: El brief de lunes en 5 minutos
Configura una Scheduled Task que corra cada lunes a las 8 AM:
Tarea: Genera mi brief semanal
Instrucciones:
Lee los archivos en /Projects/[tu-proyecto]/semana-actual/
Revisa los últimos 5 commits en GitHub
Consulta mi Google Calendar para la semana
Genera un documento en /Outputs/brief-[fecha].md con:
1. Los 3 objetivos más importantes de la semana
2. El estado actual de cada feature en desarrollo
3. Las reuniones de la semana y qué preparar para cada una
4. Una métrica clave que debo mover esta semana
El resultado: llegas al trabajo el lunes y el brief está listo. No lo generaste tú — lo generó Cowork leyendo tus propios archivos y calendario.
Flujo 2: El pipeline de contenido automatizado
Para founders que mantienen presencia en redes o newsletter como canal de adquisición:
Tarea: Pipeline de contenido semanal
Frecuencia: Viernes a las 6 PM
Instrucciones:
Lee /Inbox/ideas-contenido.md para las ideas de esta semana
Para cada idea:
1. Escribe un borrador de hilo de X (máximo 280 caracteres por tweet, 7 tweets)
2. Escribe un borrador de post de LinkedIn (máximo 300 palabras)
3. Evalúa cuál tiene más potencial viral para esta audiencia: [describe tu audiencia]
Deposita todos los borradores en /Outputs/contenido-[fecha]/
Marca con ⭐ el que recomiendas publicar primero
Flujo 3: El cierre de sprint
Al final de cada sprint (o semana, si no usas sprints formales):
Tarea: Cierre de sprint
Instrucciones:
Lee todos los archivos en /Projects/[tu-proyecto]/sprint-actual/
Revisa los commits de GitHub de los últimos 7 días
Genera el documento de cierre de sprint con:
- Features completadas (con descripción no técnica de cada una)
- Features que quedaron pendientes y por qué
- Bugs encontrados y resueltos
- Decisiones técnicas tomadas y su razonamiento
- Retrospectiva: qué funcionó bien, qué mejorar
Guarda en /Projects/[tu-proyecto]/sprints/sprint-[número].md
Para el vibe coder con múltiples proyectos
El vibe coder que maneja 2-3 proyectos simultáneos enfrenta un problema diferente: el contexto switching es costoso. Cada vez que cambias de proyecto tienes que recordar dónde quedaste, qué está bloqueado, y qué sigue. Estos flujos de trabajo minimizan ese costo.
Flujo 4: El handoff de proyecto
Cada vez que cambias de un proyecto a otro:
Tarea: Genera handoff de [PROYECTO-A] para retomar mañana
Instrucciones:
Lee los últimos archivos modificados en /Projects/[PROYECTO-A]/
Lee los últimos commits de GitHub
Lee mis notas en /Projects/[PROYECTO-A]/notas.md
Genera un documento de handoff que incluya:
- Estado exacto de lo último que estaba haciendo
- El próximo paso específico (no general) que debo dar
- Los archivos que estaba tocando
- Cualquier decision pendiente que debo tomar
- Contexto que necesito recordar para retomar sin fricción
Guarda en /Projects/[PROYECTO-A]/handoff-[fecha-hora].md
Flujo 5: El audit de dependencias
Para vibe coders con proyectos Next.js + Supabase (el stack más común en la audiencia de este blog):
Tarea: Audit de dependencias de seguridad
Frecuencia: Cada lunes
Instrucciones:
Lee el package.json en /Projects/[proyecto]/
Para cada dependencia:
1. Verifica si hay versión más reciente disponible
2. Verifica si hay CVEs conocidos en la versión actual
3. Evalúa si el update es breaking o compatible
Genera reporte en /Outputs/audit-deps-[fecha].md con:
- Dependencias críticas para actualizar (CVEs confirmados)
- Dependencias recomendadas para actualizar (versiones mayores)
- Dependencias que pueden esperar (updates menores sin urgencia)
- Comandos de npm exactos para ejecutar cada update
Flujo 6: El generador de README
Para proyectos que necesitan documentación actualizada:
Tarea: Actualiza el README de [PROYECTO]
Instrucciones:
Lee todo el código en /Projects/[proyecto]/src/
Lee el archivo .env.example si existe
Lee el package.json
Genera un README.md completo con:
- Descripción del proyecto en 2 párrafos
- Stack tecnológico con versiones
- Instrucciones de instalación paso a paso
- Variables de entorno requeridas con descripción de cada una
- Cómo correr el proyecto en desarrollo
- Cómo hacer deploy (si hay scripts configurados)
- Estructura de carpetas con explicación de cada una
Escribe en inglés (para GitHub) y guarda también versión en español
Para el freelancer técnico con clientes
El freelancer que maneja múltiples clientes tiene el problema del contexto switching multiplicado — y además tiene que comunicarse con cada cliente de forma profesional y consistente. Estos flujos atacan ambos problemas.
Flujo 7: El reporte de cliente
Tarea: Genera reporte semanal para [CLIENTE]
Frecuencia: Viernes a las 5 PM
Instrucciones:
Lee los commits de GitHub del proyecto [CLIENTE] de los últimos 7 días
Lee los tickets resueltos en /Projects/[CLIENTE]/tickets/
Lee mis notas de la semana en /Projects/[CLIENTE]/notas.md
Genera un email de reporte con:
- Saludo personalizado (el cliente se llama [NOMBRE])
- Lo que completamos esta semana (en lenguaje no técnico)
- Lo que está en progreso
- Lo que viene la próxima semana
- Preguntas o decisiones que necesito del cliente
Tono: profesional pero cercano, como si hablara con alguien que confía en mí
Máximo 300 palabras
Guarda en /Outputs/reporte-[CLIENTE]-[fecha].md
Flujo 8: El onboarding de cliente nuevo
Tarea: Configura workspace para nuevo cliente [NOMBRE]
Instrucciones:
Crea la estructura de carpetas en /Projects/[NOMBRE]/
├── src/ (código del proyecto)
├── docs/ (documentación)
├── tickets/ (issues y features)
├── comunicaciones/ (emails y notas de reuniones)
└── notas.md (mis notas de contexto del cliente)
Genera un template de notas.md con secciones para:
- Contexto del negocio del cliente
- Stack técnico del proyecto
- Convenciones acordadas
- Contactos y roles
- Fechas clave
- Notas de reuniones anteriores
Genera también un Context-[NOMBRE].md que pueda usar como briefing
cuando abra Cowork para trabajar en proyectos de este cliente
Los tres errores más comunes y cómo evitarlos
Basado en el feedback más frecuente de la comunidad que usa Cowork desde el lanzamiento en enero, estos son los tres errores que hacen que Cowork "no funcione":
Error 1: Tareas demasiado vagas
Incorrecto: "Ayúdame con el marketing" Correcto: "Genera 5 ideas de posts para LinkedIn sobre [tema], con el ángulo de [perspectiva], dirigidos a [audiencia], de máximo 300 palabras cada uno"
Cowork es extraordinariamente bueno ejecutando tareas bien especificadas. Es pésimo adivinando qué quieres. La especificidad no es limitante — es lo que desbloquea la potencia real de la herramienta.
Error 2: No configurar Context.md
El síntoma más común: "Cowork no entiende mi proyecto" o "me da respuestas genéricas." La causa: Cowork no sabe nada sobre tu proyecto porque nunca se lo dijiste de forma persistente. El Context.md es la solución.
Error 3: Primera tarea en archivos de producción
La recomendación de la guía de setup de AI Advantage Agency es específica: tu primera tarea debería ser algo de bajo riesgo en archivos no críticos. No porque Cowork vaya a romper cosas necesariamente — sino porque aprender cómo se comporta Cowork en tu entorno específico en una tarea de bajo costo es más barato que aprenderlo en un archivo que importa.
El flujo de trabajo para el día a día
Si tuvieras que implementar un solo sistema de Cowork que capturara el 80% del valor con el 20% del setup, sería este:
Mañana (automático, antes de que llegues): Scheduled Task a las 7 AM que genera tu brief del día — leyendo tu calendario, tus notas de ayer, y el estado de tus proyectos activos.
Durante el día (bajo demanda): Usas Skills específicas para tareas concretas — review-pr cuando necesitas revisar código, email-cliente cuando necesitas comunicarte, análisis-competidor cuando aparece algo relevante.
Al final del día (5 minutos de tu tiempo): Dejas un archivo en /Inbox/ con tus notas del día y las tareas que quieres delegar a Cowork overnight. Cowork las procesa mientras duermes y los resultados están en /Outputs/ cuando llegas al día siguiente.
Ese ciclo — brief automático en la mañana, skills bajo demanda durante el día, procesamiento overnight — es el patrón que más founders y vibe coders han descrito como el que más cambia su flujo de trabajo real.
Lo que Cowork no puede hacer (todavía)
Una guía honesta incluye las limitaciones, no solo los casos de éxito.
Cowork no puede tomar decisiones de negocio por ti. Puede generar análisis, opciones, y recomendaciones — pero la decisión de qué construir, a qué precio venderlo, y a quién apuntar es tuya y seguirá siéndolo.
Cowork no puede reemplazar el juicio técnico sobre arquitectura. Puede generar código, documentación, y análisis de dependencias — pero las decisiones de arquitectura que tienen consecuencias de largo plazo necesitan el criterio de alguien que entienda el contexto completo.
Cowork no funciona bien con tareas que requieren acceso a información en tiempo real que no está en tus archivos o conectores. Si necesita datos que no están disponibles en tu sistema, va a hacer lo mejor que pueda con lo que tiene — lo que a veces produce resultados desactualizados o incompletos.
Y Cowork no tiene memoria entre sesiones, como mencionamos al principio. El Context.md resuelve la mayor parte de ese problema — pero si tienes una conversación importante dentro de una sesión, guarda las conclusiones en un archivo antes de cerrar, o las perderás.
Para empezar hoy: la secuencia mínima viable
Si tienes 30 minutos ahora mismo y quieres Cowork funcionando antes del final del día:
- Descarga Claude Desktop desde claude.ai/download (requiere plan Pro o superior)
- Abre Cowork y crea tu carpeta base con la estructura de cinco carpetas
- Escribe tu Context.md — aunque sea una versión mínima de tres párrafos
- Configura tus instrucciones globales en Settings
- Conecta Google Workspace o Microsoft 365, según cuál uses más
- Crea tu primer Skill — empieza con el brief semanal porque es la que más tiempo ahorra
- Agenda tu primera Scheduled Task para mañana a las 8 AM
No necesitas todos los flujos de trabajo de esta guía desde el primer día. Necesitas uno que funcione bien, te dé resultado real, y te convenza de que el setup vale la pena. Después el sistema crece solo.
¿Ya tienes Cowork configurado y tienes flujos de trabajo que no están en esta guía? Compártelos en los comentarios — la mejor parte de los setups de productividad siempre viene de la comunidad que los usa en contextos reales.
Comentarios