$ man how-to/constraints-and-context-engines

CODE

Configura tu .gitignore antes de tu primer commit. No después. Antes. Lo esencial: *.env y .env.* - API keys, tokens, contraseñas. Una key filtrada puede costar miles. clients/ y partners/ - nombres reales, acuerdos, conversaciones. data/ - CSVs y JSONs con direcciones de correo reales, nombres de empresas, listas de leads. scripts/ - los scripts de automatización frecuentemente incluyen API keys o referencias a sistemas internos. screenshots/ - pueden capturar dashboards sensibles o nombres de clientes en pestañas del navegador. .cursor/mcp.json - contiene tus API keys para cada herramienta conectada. node_modules/ - miles de archivos de dependencias que no pertenecen al control de versiones. Prueba tu .gitignore con git status. Si un archivo que esperas que sea ignorado aparece en el estado, la regla de ignore no está funcionando. Arréglalo antes de hacer commit.

PATTERN

Nunca hardcodees API keys en archivos. Usa variables de entorno. Crea un archivo .env en la raíz de tu proyecto. Agrega tus keys: INSTANTLY_API_KEY=tu-key-aquí. Referencialas en el código con process.env.INSTANTLY_API_KEY. El archivo .env está en gitignore, así que permanece local. Crea un archivo .env.example (sin valores reales) que SÍ hagas commit. Esto documenta qué variables de entorno necesita tu sistema sin exponer las keys reales. Cuando un colaborador clona el repo, ve .env.example y sabe qué keys agregar. Para despliegues en Vercel: agrega variables de entorno en el dashboard de Vercel. La app desplegada lee del entorno de Vercel. Tu app local lee del .env. Las keys nunca tocan el control de versiones.

PATTERN

Estructura tu repo para que los datos sensibles tengan un hogar claro que siempre esté en gitignore. Los skills, el contenido y los flujos de trabajo son seguros para compartir. Los clientes, socios, exportaciones de datos y scripts con credenciales no lo son. El patrón: el contenido compartible (frameworks, plantillas, posts publicados) vive en carpetas rastreadas. El contenido sensible (datos de clientes, configuraciones de API, scripts internos) vive en carpetas con gitignore. El límite es claro y está aplicado por .gitignore, no por la memoria. Mi repo tiene tanto un repo privado de trabajo (contiene todo) como un repo público en GitHub (contiene solo contenido compartible). El skill /update-github ejecuta un escaneo pre-push que verifica nombres sensibles de socios usando una lista de bloqueo local antes de hacer push al repo público.

PRO TIP

Un .gitignore previene commits accidentales de carpetas enteras. Pero ¿qué pasa con un nombre de socio que se cuela en un mensaje de commit o un post de blog? El escaneo pre-push los atrapa. El skill /update-github escanea archivos rastreados buscando contenido sensible usando una lista de bloqueo de nombres de socios y clientes. Audita el .gitignore para confirmar que todas las carpetas sensibles están excluidas. Verifica mensajes de commit por nombres filtrados. Solo después de que todos los escaneos pasan, hace push. Puedes construir una versión más simple con un git pre-push hook. El hook ejecuta un script que hace grep por patrones que definas (nombres de empresas, dominios de email, prefijos de keys). Si encuentra una coincidencia, el push es rechazado con una advertencia. Esta es una red de seguridad, no un reemplazo para una buena configuración de .gitignore.

FORMULA

Mantén dos repos o usa separación basada en ramas. Opción A (dos repos): Tu repo privado contiene todo - skills, contenido, datos de socios, scripts. Tu repo público es un subconjunto limpio. Un script pre-push asegura que nada sensible cruce. Opción B (basada en ramas): Tu rama principal es pública. El trabajo sensible ocurre en ramas privadas que nunca se fusionan a main. Esto es más simple pero más riesgoso porque un merge equivocado expone todo. Yo uso la Opción A. El repo privado es el sistema operativo completo. El repo público en GitHub es la versión de exhibición con frameworks, contenido publicado y ejemplos de skills. El skill /update-github automatiza la sincronización con escaneo de seguridad. Lo clave: el repo público NUNCA es la copia principal de trabajo. Es una exportación curada del repo privado.