Guía
Cómo convertir actividad de GitHub en actualizaciones para clientes
GitHub registra la actividad de desarrollo. El cliente necesita saber qué cambió, qué se publicó y dónde hace falta su intervención.
Última actualización: noviembre de 2026
En esta página
Qué puedes preparar con esta guía
Usa pull requests, incidencias y versiones seleccionadas para explicar al cliente el trabajo terminado y el que ya se publicó.
Cuándo usarlo
GitHub registra la actividad de desarrollo. El cliente necesita saber qué cambió, qué se publicó y dónde hace falta su intervención.
Qué conviene evitar
Reenviar una lista de commits en bruto.
Una forma más clara de decirlo
Separa lo publicado de la próxima acción del cliente.
Estructura recomendada
- Selecciona los pull requests, incidencias, commits, etiquetas y versiones relevantes.
- Distingue el trabajo terminado de lo que consta como publicado.
- Explica el efecto del trabajo técnico.
- Menciona materiales pendientes, riesgos y próximos pasos.
- Revisa el borrador antes de enviarlo.
Actualización sobre una versión publicada
Notas del proyecto
PR #42 portada integrado PR #43 navegación móvil corregida Incidencia #18 validación de formulario cerrada Versión 1.2.0 publicada Incidencia #51 fotos pendientes
Borrador para el cliente
Hola: La versión ya está publicada. Incluye la nueva portada, la corrección de la navegación móvil y la validación del formulario. Para completar la siguiente sección de producto faltan las fotos. Cuando las reciba, terminaré la sección y la enviaré para revisión.
Por qué funciona este ejemplo
Separa lo publicado de la próxima acción del cliente.
Cambios integrados y aún sin publicar
Notas del proyecto
Validación del pago integrada Errata en texto de facturación resuelta Todavía sin versión Prueba de Safari pendiente Confirmar texto de precios
Borrador para el cliente
Hola: La validación del pago está terminada y corregimos la errata del texto de facturación. Estos cambios todavía no están publicados. Falta revisar un problema en Safari. ¿Puedes confirmar el texto definitivo de precios? Con esa confirmación y las pruebas completadas, podré preparar la actualización del lanzamiento.
Por qué funciona este ejemplo
El borrador distingue lo terminado de lo publicado y explica las condiciones para avanzar.
Buenas prácticas
- Incluye solo la actividad relevante para el cliente.
- Un pull request integrado no acredita por sí solo una publicación.
- Relaciona las incidencias cerradas con los pendientes que aún afectan al cliente.
Errores frecuentes
- Reenviar una lista de commits en bruto.
- Presentar como publicado el trabajo que solo está terminado.
- Omitir una decisión pendiente del cliente.
Cómo ayuda ClientCadence
Aprovecha el contexto del proyecto, History y la frecuencia acordada. Convierte las notas en un borrador y revísalo antes de copiarlo, enviarlo por Gmail, compartirlo en Slack o guardarlo en History.
Preguntas frecuentes
¿Lee ClientCadence el código fuente?
La integración usa metadatos de actividad seleccionados, como títulos de pull requests e incidencias, mensajes de commit, etiquetas, versiones, marcas de tiempo y enlaces. No lee archivos fuente ni inspecciona diffs.
¿Cuándo responde ClientCadence en GitHub?
Solo cuando alguien escribe un comando explícito /clientcadence o /cc en una conversación de una incidencia o un pull request. La actividad normal no genera comentarios. La integración no crea incidencias, fusiona código ni publica versiones.
¿Está disponible la importación en Free?
La importación está incluida en Pro y Agency. En Free puedes pegar notas de GitHub manualmente dentro de los límites habituales.
Guías y plantillas relacionadas
Empezar gratis con un proyecto de cliente
Conservar el contexto del proyecto, las decisiones y las últimas comunicaciones para preparar el próximo informe.
Empezar gratisLa aplicación de ClientCadence está disponible actualmente en inglés.