GitHub para marketers: convertí tu trabajo en evidencia, no en otra lista de skills

GitHub puede sentirse como un club para ingenieras, pero para una marketer u operadora también puede ser un portafolio verificable: no solo dice que sabés usar IA, muestra lo que construiste, cómo pensaste el problema y cómo otra persona puede usarlo.

La comparación con Google Drive ayuda, pero se queda corta. Un repositorio es el espacio donde vive un proyecto con sus archivos e historial. GitHub guarda cada cambio confirmado —un commit—, permite colaborar sin duplicar “final-ahora-sí-v7” y presenta cada proyecto con una página llamada README (el documento de entrada que explica qué hace y cómo usarlo).

Qué es GitHub si no escribís código

GitHub es un lugar para guardar proyectos, explicar cómo funcionan y mostrar su evolución. Para un perfil no técnico, las piezas importantes son tres:

• Tu perfil: la portada profesional con bio, links y proyectos destacados.
• Un repositorio: la carpeta de un proyecto, con archivos e historial.
• El README: la explicación humana de qué problema resuelve, para quién y cómo probarlo.

También vas a encontrar la palabra branch o rama: una línea separada de trabajo donde podés probar cambios sin alterar inmediatamente la versión principal. No necesitás dominar ramas el primer día, pero sí entender que GitHub permite revisar antes de incorporar un cambio.

No necesitás fingir que sos developer. Tu ventaja está en elegir un problema útil, definir un flujo claro y contar el impacto con el criterio de marketing que ya tenés.

Qué puede publicar una marketer u operadora

Publicá herramientas pequeñas y reutilizables, sin datos de clientes ni secretos de empresa. Cinco ideas realistas:

1. Un generador de UTMs con convenciones de campaña.
2. Una plantilla que convierte entrevistas en insights y citas.
3. Un monitor de competidores que entrega un brief semanal.
4. Un checklist para revisar campañas antes de publicarlas.
5. Una skill que transforma un brief en un plan de contenido.

Un proyecto simple que resuelve algo real vale más que seis repositorios vacíos. Si el proyecto fue creado con Claude Code, Codex u otra herramienta, decilo con transparencia: tu aporte sigue siendo definir el problema, dirigir la solución, probarla y documentarla.

Cómo crear tu perfil paso a paso

El camino más simple es preparar el perfil primero y publicar después un solo proyecto bien explicado.

1. Abrí la cuenta y protegela

Creá tu cuenta, elegí un usuario profesional, completá foto, bio, ubicación y enlaces, y activá autenticación de dos factores. La bio debe decir qué hacés y para quién, no acumular nombres de herramientas.

Ejemplo: “Marketing + AI operations. Construyo sistemas simples para convertir research en decisiones y contenido”.

2. Creá el README de tu perfil

GitHub muestra un README especial cuando creás un repositorio público con exactamente el mismo nombre que tu usuario y un archivo README.md en la raíz.

Usá esta estructura:

Quién soy: dos líneas sobre tu experiencia y el tipo de problemas que resolvés. Qué estoy construyendo: dos o tres proyectos concretos. Cómo trabajo: research, criterio, sistemas, experimentación y medición. Prueba de trabajo: links a demos, casos, artículos o repositorios. Contacto: un canal profesional.

3. Publicá tu primer repositorio

Creá un repositorio público, poné un nombre que una humana entienda y activá la opción para incluir un README. Subí únicamente materiales que podés compartir.

No publiques tokens, contraseñas, bases de datos, briefs confidenciales, listas de clientes ni archivos internos. Un token es una credencial digital que puede permitir acceso a una cuenta o servicio. Si el proyecto necesita credenciales, documentá el nombre de las variables, nunca sus valores.

Antes de elegir “público”, hacé una revisión desde cero:

1. buscá nombres de clientes, correos, teléfonos y datos personales;
2. revisá el historial, porque borrar un secreto del archivo actual no siempre lo elimina de commits anteriores;
3. agregá un .gitignore (una lista de archivos que Git no debe guardar) para credenciales y archivos locales;
4. incluí una licencia si querés permitir que otras personas reutilicen el trabajo;
5. si un secreto llegó al repositorio, revocalo y reemplazalo; no alcanza con borrarlo.

4. Escribí un README que venda la idea sin vender humo

Tu README debería responder estas preguntas en este orden:

1. ¿Qué problema resuelve?
2. ¿Para quién es?
3. ¿Qué entra y qué entrega?
4. ¿Cómo lo pruebo?
5. ¿Qué decisiones tomaste?
6. ¿Qué limitaciones tiene?
7. ¿Qué aprendiste?

Incluí una captura o GIF, un ejemplo real sin información sensible y pasos de instalación que otra persona haya probado. Una demo es una versión que permite ver o probar el resultado sin tener que entender todo el proyecto. Si todavía no hay demo, decilo; no prometás una app terminada.

El README mínimo, listo para copiar

# Nombre del proyecto Una frase que explica el resultado. ## El problema Quién lo tiene y por qué importa. ## Cómo funciona Entrada → proceso → salida. ## Probarlo Enlace a la demo o pasos exactos. ## Privacidad y límites Qué datos usa, qué no hace y qué requiere revisión. ## Mi aporte Qué definiste, construiste, probaste y aprendiste.

5. Fijá de tres a cinco proyectos

GitHub permite destacar repositorios y gists en el perfil. Elegí entre tres y cinco piezas que juntas cuenten una historia: una herramienta, una automatización, una skill, un análisis y un proyecto colaborativo. No fijés todo; curar también es una habilidad.

Tu primer proyecto con un asistente de código

Podés pedirle a Claude Code, Codex u otro asistente que te ayude a construir y publicar, pero mantené el proceso bajo tu control.

Empezá con este brief:

Quiero crear una herramienta pequeña para [audiencia] que resuelva [problema]. La entrada será [dato] y la salida [resultado]. Antes de escribir código, proponé el flujo, los riesgos de privacidad y una prueba de aceptación. Trabajá en pasos pequeños. No publiques nada ni uses credenciales sin mi aprobación. Al final, prepará un README para una persona no técnica.

Probá el resultado con tres casos: uno normal, uno incompleto y uno extraño. Después pedí una explicación de los archivos creados. Publicar algo que no entendés no fortalece tu portafolio.

Un plan de siete días que sí podés terminar

No necesitás convertir GitHub en otro proyecto infinito.

• Día 1: cuenta, 2FA, bio y links.
• Día 2: README de perfil.
• Día 3: elegí un problema que ya resolvés manualmente.
• Día 4: construí la versión mínima.
• Día 5: probala y quitá datos sensibles.
• Día 6: escribí el README y grabá una demo corta.
• Día 7: publicá, fijá el repositorio y compartí qué aprendiste.

Tu objetivo es dejar una evidencia clara de que podés transformar un problema en un sistema útil.

Errores que hacen que un perfil se vea menos profesional

Un perfil pierde credibilidad cuando tiene repositorios sin explicación, código que no corre, nombres genéricos o datos que no deberían ser públicos. También cuando todos los textos parecen generados y no explican ninguna decisión.

Antes de compartir, revisá:

• ¿Una persona entiende el valor en 20 segundos?
• ¿Puede ver o probar el resultado?
• ¿Está claro qué hiciste vos y qué hizo la IA?
• ¿Quitaste toda información privada?
• ¿Los enlaces funcionan?

GitHub no reemplaza LinkedIn. LinkedIn cuenta tu trayectoria; GitHub puede demostrar cómo trabajás. Juntos hacen una historia mucho más creíble.

Fuentes oficiales

• Qué es un README y qué debería incluir, GitHub Docs.
• Usar tu perfil de GitHub para fortalecer tu currículum, GitHub Docs.
• Personalizar tu perfil, GitHub Docs.
• Eliminar datos sensibles de un repositorio, GitHub Docs.

Para documentar un proceso reusable dentro del proyecto, seguí CLAUDE.md y Skills: cómo darle buen contexto a tu IA. Si construís con un agente, revisá también seguridad y estándares para agentes de IA.

Si sos una mujer que quiere convertir lo que aprende con IA en evidencia visible de su trabajo, sumate gratis a Pioneras en IA.