plantillas de 3 niveles (3-Tier Templates): solo, mid, corporate

Tiempo: ~25 min de teoría + 40 min de práctica

Lo esencial

Cuando buscas dónde vivir, eliges según tu caso. Un estudio de 30 m² para un freelancer, una casa para una familia de cinco, una oficina para una empresa de 50 personas. Son edificios distintos con infraestructura distinta. En un estudio no hace falta un cuarto de servidores. En una oficina de 50 personas no alcanza con un solo enchufe.

Lo mismo pasa con la plantilla (template) para un proyecto nuevo. Una plantilla para todo es, o una complejidad de más para el emprendedor en solitario (pasa 2 semanas entendiendo audit/, engineering-standards/ y checklists de SOC2 en lugar de lanzar su MVP), o se queda corta para un cliente corporativo (el contrato B2B exige un data processing agreement y el proyecto no lo tiene).

La solución es una matriz de 3 niveles (tiers) × 8 tipos de proyecto. Tres niveles de infraestructura (solopreneur / mid-business / corporate) multiplicados por ocho tipos de negocio (SaaS, contenido, servicios, etc.). Son 24 configuraciones listas. Además están los módulos LEGO: agregas solo lo que de verdad necesitas, nada más.

🎨 Imagínalo así: una plataforma para varios proyectos es una fábrica de negocios. Antes salía de la fábrica un solo modelo de camión, igual para el trailero que para el jardinero. Ahora hay una línea: un auto para uno, una minivan para la familia, un tráiler para la logística. En cada etapa solo cambian los módulos (motor, carrocería, electrónica); el chasis y la forma de armarlo son los mismos.

Conceptos clave

• Tier (nivel): el nivel de infraestructura del proyecto: solopreneur, mid-business, corporate. No lo definen las ambiciones, sino la carga real (equipo, presupuesto, cumplimiento normativo)
• Base: los cimientos del proyecto, iguales en todos los niveles: 4 archivos (CLAUDE.md, MEMORY.md, HANDOFF.md, README.md) + 3 carpetas (assets, decisions, tasks)
• Módulos LEGO: 17 bloques opcionales que se agregan cuando hacen falta: brand, departments, analytics, customers, tests, deployments, prps, prompts, explorations, compliance, security, audit, governance, infrastructure, contracts, reporting, context
• Project type (tipo de proyecto): la categoría que define el conjunto de módulos por defecto: SaaS, Content, Service, Marketplace, Tool, Community, Education, Build-to-Sell
• Non-negotiable (innegociable): los módulos obligatorios en todos los niveles: MEMORY.md y HANDOFF.md. Sin ellos, cada nueva sesión de Claude empieza de cero
• Detachability (separabilidad): el requisito de que el proyecto pueda vivir sin la plataforma. Si la plataforma común se cierra, el proyecto tiene su propio CLAUDE.md, sus propios datos del dueño y su propio BRAND-VOICE.md. No depende del "padre"
• Portfolio Pattern: infraestructura común de la plataforma (CORE) + proyectos independientes con identidad propia
• Decision tree (árbol de decisión): el algoritmo para elegir nivel y módulos: 4 preguntas → configuración lista
• Smart suggestions: el comando /audit-needs, donde Claude analiza el proyecto y sugiere qué módulos agregar
• Module promotion (ascenso): el patrón para subir un proyecto de nivel: solo → mid → corporate cuando crece

Teoría

Para qué tres niveles

Una sola plantilla para todo es un antipatrón. Te lo explico con números.

El emprendedor en solitario que arma un MVP en un fin de semana necesita empezar a programar en 10 minutos. Si la plantilla trae carpetas engineering-standards/, audit/, compliance/gdpr.md, security/threat-model.md, pasa 4 horas entendiendo qué es eso y para qué sirve. Al final, o borra la mitad (y perdió el tiempo leyéndola) o la deja y la olvida (código muerto en el proyecto).

El cliente corporativo con contrato B2B es lo contrario. Cuando sus abogados preguntan "¿dónde está su Data Processing Agreement y su política de notificación de brechas?", hay que mostrar documentos listos en 5 minutos, no escribirlos desde cero en 3 días.

La solución es una jerarquía de tres niveles. Cada nivel agrega solo lo que hace falta en esa etapa.

🎨 Imagínalo así: la ropa. Solo: playera y jeans (lo mínimo, cómodo, rápido). Mid-business: camisa y corbata (ya recibes clientes). Corporate: traje y mancuernillas (te dejan pasar al piso de la alta dirección de un banco).

Nivel 1: Solopreneur, el estudio de 30 m²

Perfil: 1 persona. Presupuesto de $0-500 al mes. Enfoque: MVP, salir rápido al mercado, validar. Los procesos manuales están bien.

Qué incluye (base/):

• CLAUDE.md: el cargador, cómo trabajar con el proyecto
• MEMORY.md: lo que ya sé de este proyecto (un resumen para recuperar el contexto)
• HANDOFF.md: por si le pasas el proyecto a otro Claude o a un desarrollador
• README.md: la cara externa (para usuarios, GitHub)
• assets/: archivos estáticos, logotipos, capturas de pantalla
• decisions/: bitácora de decisiones (un archivo por decisión)
• tasks/: tareas actuales

Qué NO incluye (a propósito):

• ❌ Subagentes por proyecto (se usan los agentes comunes de la plataforma)
• ❌ Hooks por proyecto (se heredan del CORE)
• ❌ Documentos de cumplimiento (a nadie solo le piden SOC2)
• ❌ Engineering Standards: no hay a quién gobernar, estás solo
• ❌ Registro de auditoría por proyecto (con el del CORE basta)
• ❌ Contratos: todavía no hay B2B

Costo: ~5-15 KB de archivos markdown. Tiempo de configuración: 5-10 minutos con /new-project.

Antipatrón: el emprendedor en solitario agrega engineering-standards/ "para el futuro". Un año después la carpeta de governance está vacía y el proyecto cerró. Tiempo perdido. Regla: no agregues lo que no necesitas hoy.

Nivel 2: Mid-business, la casa familiar

Perfil: 2-10 personas (contando freelancers). Presupuesto de $500-5000 al mes. Hay clientes que pagan. La automatización empieza a ahorrar dinero. Aparecen los procesos de despliegue.

Qué se agrega a la base:

• BRAND-VOICE.md: un estilo único para el equipo (si 3 personas escriben contenido, hace falta un solo tono)
• ARCHITECTURE.md: el diagrama del sistema (un desarrollador nuevo ve cómo se conecta todo)
• BUDGET.md: gastos operativos por mes
• ROADMAP.md: lo que se planea para 3-6 meses
• departments/: áreas funcionales (marketing, soporte, operaciones)
• analytics/: métricas, tableros de KPI
• customers/: datos de clientes seudonimizados (no datos personales en bruto)
• tests/: pruebas automáticas (Vitest, Playwright)
• deployments/: procedimientos de staging + producción

Módulos opcionales según el contexto:

• prps/: Product Requirement Prompts (para desarrollar funciones con /generate-prp)
• prompts/: biblioteca de prompts reutilizables
• explorations/: experimentos de I+D que no van a producción

Costo: ~50-150 KB. Tiempo de configuración: 30-60 minutos con /new-project --tier=mid + /add-module.

Patrón: espera a la señal. No agregues analytics/ mientras no tengas 10 clientes que pagan: no hay nada que medir. Agrégalo cuando las Recent Decisions de MEMORY.md mencionen métricas 3 veces seguidas.

🎨 Imagínalo así: remodelar la casa. Primero la vives: descubres dónde faltan enchufes, dónde hay mala luz, dónde rechina el piso. Luego arreglas puntualmente. No haces una remodelación total antes de vivirla.

Nivel 3: Corporate, el edificio de oficinas

Perfil: más de 50 personas (o 5-10 personas con contratos B2B enterprise). Presupuesto de $5000 o más al mes. El cumplimiento normativo es obligatorio: SOC2 / GDPR / HIPAA según la industria. Los abogados exigen un registro de auditoría.

Qué se agrega a mid-business:

• ENGINEERING-STANDARDS.md: la estructura de toma de decisiones (quién aprueba qué)
• compliance/: el conjunto completo: base de GDPR, CCPA, aviso de privacidad, términos de servicio, política de cookies, política de conservación, notificación de brechas, clasificación de datos, data processing agreement, checklist de auditoría
• security/: modelo de amenazas, manejo de secretos, runbook de respuesta a incidentes
• audit/: registros de solo-agregar de todas las acciones importantes (para auditorías SOC2)
• infrastructure/: IaC, DR (recuperación ante desastres), estrategia de respaldos
• contracts/: plantillas de MSA, SLA y NDA para clientes B2B
• reporting/: revisiones trimestrales del negocio, reportes para el consejo

Costo: ~300 KB - 1 MB. Tiempo de configuración: 4-8 horas con /new-project --tier=corporate + adaptar a mano los documentos legales.

Antipatrón: el emprendedor en solitario salta al nivel corporate porque "quiere verse serio". Al mes descubre que compliance/gdpr.md tiene una plantilla genérica que no aplica a su situación concreta. Igual necesita la revisión de un abogado. Tiempo perdido.

Regla: el nivel corporate se activa con una señal externa: el primer cliente enterprise en el pipeline, un abogado pidió un DPA, un auditor empieza una evaluación de preparación para SOC2. No "por si acaso".

8 tipos de proyecto × 3 niveles

El Portfolio Pattern contempla 8 tipos de proyecto. Cada uno tiene un conjunto de módulos por defecto.

Build-to-Sell es especial: su tarea es estar listo para entregarse en cualquier momento. Por eso incluso el nivel solo trae un HANDOFF.md reforzado (para el futuro comprador). En mid-business ya es el conjunto completo, porque un negocio en venta debe mostrar ARR, métricas y documentación.

Innegociables en todos los niveles

Dos archivos son obligatorios en todos los niveles. Sin ellos, cada sesión de Claude empieza de cero.

1. MEMORY.md: el resumen rápido del proyecto

Cuando una nueva sesión de Claude abre el proyecto, lo primero que lee es MEMORY.md. En 2 minutos recupera el contexto: la fase, las decisiones recientes, los bloqueos abiertos, el stack técnico, las métricas principales.

Sin MEMORY.md:

• Claude lee todo CLAUDE.md + README.md + los últimos 10 commits + revisa la estructura: 10 minutos
• Al minuto 10 empieza a trabajar, pero con el contexto incompleto
• Preguntas aclaratorias constantes al dueño del proyecto

Con MEMORY.md:

• 2 minutos: contexto completo recuperado
• Claude propone de inmediato el siguiente paso
• Un mínimo de preguntas sobre el contexto

2. HANDOFF.md: el archivo de continuidad

¿Y si el dueño se enferma? ¿Si decide vender el proyecto? ¿Si contrata a un desarrollador? HANDOFF.md es un documento autosuficiente para un lector externo que no conoce tu plataforma.

Debe responder:

• ¿Qué hace este proyecto?
• ¿Cuál es su estado actual (ingresos, usuarios, bloqueos)?
• ¿Dónde está el código, dónde el despliegue, dónde los accesos de administrador?
• ¿Quiénes son los socios y clientes (seudonimizados)?
• ¿Qué riesgos y pendientes hay?

Sin HANDOFF.md, el proyecto no es separable. No sobrevivirá si la plataforma común se cierra o si el dueño se lo pasa a un heredero. Eso rompe el principio de separabilidad de los proyectos (detachability).

Módulos LEGO: el catálogo

Hay 17 módulos disponibles con /add-module. Se agrupan por función.

Marca e identidad (1):

• brand/: BRAND-VOICE.md, guía de marca, identidad visual

Operaciones (4):

• departments/: áreas funcionales (marketing, soporte, operaciones, finanzas)
• analytics/: métricas, KPI, tableros
• customers/: datos de clientes seudonimizados
• reporting/: revisiones periódicas (semanales/mensuales/trimestrales)

Ingeniería (6):

• tests/: configuración de Vitest/Playwright/Jest
• deployments/: procedimientos de staging + producción
• prps/: Product Requirement Prompts para desarrollar funciones
• prompts/: biblioteca de prompts reutilizables
• explorations/: experimentos de I+D
• infrastructure/: IaC, DR, estrategias de respaldo

Cumplimiento y riesgo (5):

• compliance/: GDPR, CCPA, privacidad, términos de servicio, políticas de conservación
• security/: modelo de amenazas, secretos, respuesta a incidentes
• audit/: registros de solo-agregar
• engineering-standards/: estructura de toma de decisiones
• contracts/: plantillas de MSA, SLA, NDA

Contexto (1):

• context/: archivos de conocimiento externos (especificaciones, artículos, glosarios propios del proyecto)

Árbol de decisión: cómo elegir el nivel

Pregunta 1: ¿Cuántas personas trabajan activamente en el proyecto?
  1 persona → nivel solo (empieza aquí, sube después)
  2-10 personas → nivel mid-business
  más de 10 personas O hay clientes B2B enterprise → nivel corporate

Pregunta 2: ¿Hay requisitos regulatorios?
  No → la decisión de la pregunta 1
  GDPR (usuarios en la UE) / CCPA (usuarios en California) → como mínimo mid-business + módulo compliance
  HIPAA / SOC2 / regulaciones financieras → corporate

Pregunta 3: ¿Preparas el proyecto para venderlo?
  No → la decisión de las preguntas 1-2
  Sí → nivel + 1 (como mínimo mid-business aunque estés solo). HANDOFF.md reforzado
  Listo para venderse ahora → corporate (le muestra madurez al comprador)

Pregunta 4: ¿Qué ingresos tiene?
  $0-1000 al mes → solo
  $1000-10000 al mes → mid-business
  más de $10000 al mes O contratos enterprise → corporate

Si las preguntas dan resultados distintos, tomas el nivel más alto. Es mejor pasarse que quedarse corto cuando crezca la carga.

Ascenso: pasar de un nivel a otro

El proyecto puede crecer. De solo a mid-business pasa cuando:

• Llegó una segunda persona al equipo (freelancer, socio)
• Hay ingresos estables de los primeros $500-1000 al mes
• Hay más de 10 clientes que pagan
• Las decisiones empiezan a discutirse (hace falta decisions/)

Disparadores de mid a corporate:

• El primer prospecto B2B enterprise (un trato de más de $10K al año)
• Los abogados de los prospectos pidieron documentos de cumplimiento
• Una auditoría o due diligence (para vender el proyecto o para una ronda de inversión)
• Un equipo de más de 10 personas

El proceso de ascenso:

1. Ejecuta /audit-needs: Claude te dirá qué módulos recomienda
2. El dueño del proyecto aprueba la lista
3. /add-module compliance / /add-module security / etc.
4. Llena las plantillas genéricas con datos específicos
5. Actualiza MEMORY.md con el nuevo nivel

Antipatrón: el ascenso preventivo. No subas de nivel porque "quieres verte serio". Subir es una reacción a una señal externa, no una ambición interna.

Separabilidad: un requisito crítico

Cada proyecto debe sobrevivir a la muerte de la plataforma. Si la plataforma se cierra mañana, cualquier proyecto, por ejemplo projects/my-newsletter/, debe seguir funcionando por su cuenta.

Qué significa en la práctica:

• ✅ Su propio CLAUDE.md (no solo un @import del CORE)
• ✅ Su propio BRAND-VOICE.md (no depende de las reglas de comunicación del dueño de la plataforma)
• ✅ Sus propios datos del dueño (seudonimizados si hace falta)
• ✅ Sus propios scripts de despliegue (no llaman directamente a la infraestructura común de la plataforma)
• ✅ Un HANDOFF.md autosuficiente para un lector externo

Qué se vale tomar prestado:

• Playbooks compartidos mediante una referencia del tipo @~/platform/... (si el proyecto sigue dentro de la plataforma)
• Agentes y hooks compartidos (pero al separarse, se copian al proyecto)

🎨 Imagínalo así: un hijo que creció debe poder vivir aparte de sus padres. No significa que tenga que irse. Pero puede hacerlo en cualquier momento. La plataforma es el padre; los proyectos, los hijos adultos.

🧪 Práctica

Los comandos /new-project, /add-module, /audit-needs y /handoff son comandos personalizados del repositorio de trabajo del autor, y las carpetas projects/_template/ no están publicadas. Si no los tienes, créalos tú: en Claude Code, un comando personalizado es un skill (el archivo .claude/skills/<nombre>/SKILL.md); los archivos viejos .claude/commands/<nombre>.md también siguen funcionando. Pídele a Claude que arme ese comando a partir de la descripción de la lección.

Paso 1: crea un proyecto nuevo con /new-project

# En Claude Code, con la carpeta de tu plataforma abierta
/new-project my-newsletter

Claude te hará 4 preguntas (el árbol de decisión de arriba):

• ¿Cuántas personas?
• ¿Requisitos regulatorios?
• ¿Lo preparas para venderlo?
• ¿Ingresos actuales?

Con tus respuestas propondrá un nivel + módulos. Lo apruebas y se crea la estructura.

Paso 2: revisa la estructura creada

ls projects/my-newsletter/

En el nivel solo verás:

projects/my-newsletter/
├── CLAUDE.md          (cargador)
├── MEMORY.md          (resumen, obligatorio)
├── HANDOFF.md         (continuidad, obligatorio)
├── README.md          (cara externa)
├── AGENTS.md          (enlace simbólico a los agentes del CORE)
├── assets/            (logotipos, capturas)
├── decisions/         (bitácora)
└── tasks/             (actuales)

Mid-business agregará: BRAND-VOICE.md, ARCHITECTURE.md, BUDGET.md, ROADMAP.md, analytics/, customers/, departments/, deployments/, tests/.

Corporate agregará a mid: ENGINEERING-STANDARDS.md, compliance/, security/.

Paso 3: agrega un módulo cuando haya señal

Pasó un mes. my-newsletter ya tiene 50 suscriptores que pagan. Hay que empezar a medir.

/add-module analytics

Claude:

1. Revisará la compatibilidad (¿ya hay analytics? no, lo agregamos)
2. Copiará la plantilla de projects/_template/modules/analytics/
3. La adaptará al nivel actual
4. Actualizará MEMORY.md (anotará que se agregó el módulo)
5. Propondrá el siguiente paso (llenar las métricas iniciales)

Paso 4: sugerencias inteligentes con /audit-needs

/audit-needs

Claude analizará MEMORY.md, las decisiones recientes y la estructura actual, y propondrá:

Recommended modules for my-newsletter:
✅ ALREADY HAVE: brand, analytics
🔵 SUGGEST: customers (you mentioned customer feedback 3 times in decisions/)
🟡 OPTIONAL: prompts (you have 5 reusable prompts in scattered places)
⚪ NOT NEEDED YET: compliance (no EU/CA users mentioned)

Approve? [y/n]

Tú decides qué agregar. Claude no decide solo: solo sugiere.

Paso 5: ascenso de solo a mid-business

# Después del disparador (una segunda persona, los primeros $1K al mes)
/audit-needs --tier=mid-business

Claude mostrará el análisis de brechas:

Current: solo tier
Target: mid-business tier

Missing modules for mid-business:
- BRAND-VOICE.md (need for team consistency)
- ARCHITECTURE.md (onboard new developer)
- BUDGET.md (track operational costs)
- ROADMAP.md (3-6 month plan)
- departments/ (functional areas)
- analytics/ (KPIs tracking)
- deployments/ (staging procedure)

Estimated time to setup: 1-2 hours
Estimated maintenance overhead: +30 min/week

Proceed with promotion? [y/n]

Paso 6: comprueba la separabilidad

Una vez por trimestre, revisa que el proyecto sea separable.

/handoff projects/my-newsletter

Claude generará un HANDOFF.md para un lector externo. Léelo como si fueras un desconocido:

• ¿Se entiende qué hace el proyecto?
• ¿Hay métricas financieras (ingresos, costos)?
• ¿Se indican las dependencias críticas (claves de API, hosting)?
• ¿Los datos personales están seudonimizados?
• ¿Se puede correr el proyecto sin la plataforma común?

Si la respuesta es "no" en al menos una, corrígelo antes del siguiente trimestre.

Paso 7: escenario Build-to-Sell (si aplica)

Si construyes un proyecto para venderlo:

/new-project saas-tool --type=build-to-sell

Por defecto ya trae un HANDOFF.md reforzado. Además necesitas:

1. Seudonimización completa de los datos del dueño
2. Inventario de activos: la lista de todo (dominios, cuentas, propiedad intelectual)
3. Resumen financiero: estado de resultados de los últimos 12 meses (si aplica)
4. Lista de clientes: seudonimizada (para la due diligence del comprador)
5. Plan de transición: cómo tomará el proyecto el nuevo dueño (cambio de accesos, redirección de pagos)

# 6 meses antes de la venta
/add-module reporting  # revisiones trimestrales del negocio: suben la valuación
/add-module contracts  # MSA/SLA listos para el comprador
/audit-needs --tier=corporate  # análisis de brechas para una venta premium

Paso 8: práctica: elige el nivel para tus ideas

Toma 3 de tus proyectos actuales o planeados y aplícales el árbol de decisión:

Fíjate: la respuesta más exigente define el nivel. Si una sola pregunta da corporate (por ejemplo, HIPAA), todo el proyecto es corporate.

⚠️ Antipatrones

❌ Una plantilla para todo. Antes había una sola plantilla grande que lo traía TODO. El emprendedor en solitario pasaba 4 horas leyéndola, borraba la mitad y se confundía con el resto. La solución: un sistema modular con una elección explícita de nivel.

❌ Ascenso preventivo. El emprendedor en solitario agrega engineering-standards/, compliance/, audit/ "por si acaso" o porque "quiere verse serio". Seis meses después, las carpetas están vacías: tiempo perdido. Regla: el ascenso es reactivo, no proactivo. Una señal externa dispara la subida.

❌ Saltarse los innegociables. El emprendedor borra MEMORY.md porque "igual lo tengo todo en la cabeza". Dos semanas después, cada nueva sesión de Claude no conoce el contexto y pierde 30 minutos averiguándolo. MEMORY.md y HANDOFF.md son obligatorios en todos los niveles.

❌ Proliferación de módulos. Un proyecto mid-business incluyó los 17 módulos "porque estaban disponibles". Un año después: la carpeta explorations/ con un solo archivo, contracts/ vacía, audit/ sin abrir nunca. Regla: agrega un módulo cuando haya una señal de que lo necesitas AHORA.

❌ Copiar entre niveles sin adaptar. Copiaste compliance/gdpr.md de la plantilla tal cual, con marcadores genéricos como {{COMPANY_NAME}}. El abogado del prospecto lo ve y pierde la confianza. Regla: la plantilla es un punto de partida, no el documento final.

❌ La separabilidad se rompe por accidente. En el proyecto escribiste import config from '/Users/me/platform/shared/...': ahora el proyecto no funciona si mueves la carpeta. Regla: todos los imports, relativos o mediante enlaces simbólicos explícitos en shared/.

❌ Mezclar niveles dentro del proyecto. El proyecto está en nivel corporate, pero decisions/ está vacía (no se anotan las decisiones). Eso no es corporate: es solo con una estructura ampliada. El nivel no son solo archivos: es también la disciplina de usarlos.

❌ Build-to-Sell sin preparar el HANDOFF. Lanzaste un proyecto para venderlo, pero en HANDOFF.md dice "ya le entenderás". El comprador ve falta de transparencia y pide descuento. Build-to-Sell = HANDOFF.md como activo del producto, que se actualiza siempre.

🔗 Relacionado con

Claude.md: el prompt de sistema de tu proyecto: qué escribir en el cargador del proyecto. Esta lección lo complementa: qué nivel elegir para el CLAUDE.md.

Portfolio Detachability: proyectos separables: infraestructura común de la plataforma vs proyectos independientes. Aquí está la práctica de crear un proyecto así teniendo en cuenta la separabilidad.

Memoria y continuidad: por qué MEMORY.md es innegociable en todos los niveles. Sobre la memoria automática de Claude Code, ver Claude.md: el prompt de sistema de tu proyecto.

Orquestación multiagente: el nivel corporate agrega subagentes por proyecto. Solo usa los agentes compartidos del CORE.

Arquitectura de skills: qué skills se necesitan en cada nivel (solo: la biblioteca compartida; corporate: puede tener skills propios del proyecto).

✅ Punto de control

Antes de pasar a la siguiente lección, asegúrate de que:

• Puedes explicar con tus palabras, usando una imagen, la diferencia entre los niveles solo / mid-business / corporate
• Conoces los 8 tipos de proyecto y qué conjunto de módulos trae cada uno por defecto
• Entiendes por qué MEMORY.md y HANDOFF.md son innegociables en todos los niveles
• Aplicaste el árbol de decisión al menos a uno de tus proyectos reales o planeados
• Ejecutaste /new-project con el nivel correcto y revisaste la estructura
• Sabes cuándo agregar un módulo (con señal) y cuándo no (preventivo: antipatrón)
• Entiendes el requisito de separabilidad y por qué es crítico
• Ejecutaste /audit-needs al menos en un proyecto existente
• Conoces los disparadores del ascenso solo → mid → corporate
• Puedes explicar por qué Build-to-Sell es un caso especial que requiere un HANDOFF reforzado

Fuentes

Plantillas y comandos del repositorio de trabajo del autor del curso (no están publicados; puedes armarlos tú con la descripción de la lección):

• projects/_template/base/: los cimientos de todos los niveles
• projects/_template/modules/: 17 módulos LEGO
• projects/_template/business/: valores por defecto del nivel mid-business
• projects/_template/corporation/: valores por defecto del nivel corporate
• .claude/commands/new-project.md: arrancar un proyecto nuevo
• .claude/commands/add-module.md: agregar un módulo
• .claude/commands/list-modules.md: qué hay disponible
• .claude/commands/audit-needs.md: sugerencias inteligentes
• Principios de la plataforma: el principio de separabilidad de los proyectos (detachability)
• Reglas de separación del contexto: qué NO duplicar entre el CORE y los proyectos
• Descripción de la fábrica de plantillas: el Portfolio Pattern y los 8 tipos de proyecto
• MEMORY.md (plantilla): la estructura del archivo innegociable

Siguiente lección

→ Portfolio Detachability: proyectos separables