Guía7 min de lectura

Guía de demo README para agentes de IA

Ayude a quien lee el repositorio a entender una tarea.

Planifique una demo README de una aplicación web creada por un agente de IA mostrando una tarea comprobada que ayuda a entender el proyecto.

Ver cómo funcionaLos primeros 60 segundos de vídeo son gratuitos, con marca de agua.
Verifique su correo electrónico para descargarlo.

Una demo README para un agente de IA debe ayudar a quien lee el repositorio a entender un resultado útil del navegador sin pedirle que lo deduzca de las notas de implementación. El recurso más eficaz es breve y concreto. Parte de un estado reconocible, muestra una acción con sentido y termina en el resultado que hace comprensible el proyecto. Eso basta para orientar a un lector que está decidiendo si explorar el repositorio, ejecutar la app o hablar de ella con quien la hizo.

Un README tiene un cometido distinto al de una página de lanzamiento. Da contexto a alguien que ya está cerca del proyecto, pero sigue sin poder suponer que conoce la ruta, los datos o el uso previsto. Un vídeo breve y comprobado puede responder a la primera pregunta práctica, qué le permite hacer esta app a una persona. No debe afirmar que toda ruta está lista, documentar cada instrucción usada por un agente ni convertir una interfaz inacabada en una promesa amplia.

GogoScreen prepara un MP4 narrado y editado a partir de la URL de una aplicación web y una indicación de una sola línea sobre el flujo que mostrar. Puede usar una cuenta de demostración cuando una ruta relevante está detrás de un inicio de sesión. Entre sus funciones de edición declaradas están los zooms en los clics, el suavizado del cursor, los cortes de silencios muertos y los subtítulos. Esas funciones ayudan a que un flujo seleccionado sea más fácil de seguir, pero una renderización puede fallar o necesitar un segundo intento. Quien añade un recurso a un README debe comprobar la ruta y el candidato antes de tratarlo como una herramienta de orientación útil.

¿Qué pregunta debe responder una demo README?

Una demo README debe responder a la primera pregunta que se hace un lector técnicamente curioso tras leer el nombre del proyecto y la frase inicial. La pregunta suele referirse a un resultado, no a una arquitectura. Un lector puede querer ver si la app crea un registro, convierte una entrada en un resultado, ayuda a un usuario a decidir o cambia un estado visible. Elija una tarea que haga concreto el resultado central sin exigir una secuencia de configuración extensa.

Utilice una estructura de inicio, acción y resultado. El inicio muestra suficiente contexto para que el lector identifique la función. La acción es la única elección u operación que importa. El resultado hace visible el valor en pantalla. Esta estructura es especialmente útil cuando un agente ha producido muchas pantallas con rapidez, porque le da al README una explicación estable que no depende de una lista larga de funciones.

Indique el resultado del navegador que quien lee el repositorio debe entender primero.
Seleccione una acción que haga visible ese resultado sin una preparación larga.
Mantenga el estado final en pantalla el tiempo suficiente para que el lector lo inspeccione.

La guía de vídeo de demo para agentes de IA explica cómo un flujo comprobado se convierte en un traspaso humano práctico. La guía de vídeo de demo de lanzamiento para agentes de IA aplica la misma estructura a un lanzamiento público, donde la revisión de afirmaciones es más amplia. Para un cambio que aún se está considerando, la guía de vídeo de demo de PR para agentes de IA mantiene la evidencia centrada en un comportamiento propuesto.

¿Cómo se elige la ruta correcta?

Elija una ruta que un lector pueda reconocer sin historial de cuenta privado. Ábrala manualmente y repita la tarea prevista antes de preparar un candidato. Compruebe el estado inicial, las redirecciones, los avisos de cookies, los estados vacíos y las capas que puedan interrumpir la secuencia. Una ruta estrecha cercana a la acción útil suele ser mejor que la pantalla de inicio, sobre todo cuando la pantalla de inicio contiene navegación pero ninguna evidencia de lo que hace la app.

Prepare datos no sensibles que hagan comprensible el resultado. No incluya un nombre de cliente, una URL de cliente, un documento privado ni una credencial en la ruta, el vídeo o el README. Si la tarea necesita autenticación, utilice una cuenta de demostración descartable mediante el proceso aprobado. En GogoScreen, las credenciales se cifran, se usan para una única renderización y después se eliminan. Si primero se planifica un storyboard, las credenciales se conservan cifradas durante esa sesión y se eliminan como máximo dos horas después de su último uso. Quien prepara el recurso no debe solicitar, copiar ni publicar esas credenciales.

Necesidad del lector	Elección de ruta	Evidencia que mantener visible
Entender el resultado del proyecto	Empiece cerca de la primera tarea reconocible.	El contexto que explica la tarea.
Inspeccionar el cambio importante	Use una ruta con una acción del usuario.	La acción y el estado del navegador resultante.
Decidir si explorar más	Termine en el resultado seleccionado.	El límite de lo que muestra el recurso breve.

La guía de vídeo de demo de software a partir de una URL cubre la preparación de la ruta para una demostración basada en navegador. La guía de vídeo de registro de cambios para agentes de IA aplica la misma evidencia enfocada a un cambio aceptado. Ambos enfoques funcionan solo cuando el estado inicial y el resultado son suficientemente claros para un lector que no ha abierto antes la app.

¿Cómo debe describir la indicación la tarea del README?

Escriba la indicación en el lenguaje que ve un lector en la interfaz. Nombre el punto de partida, la acción y el resultado visible. Por ejemplo, una indicación puede pedir abrir un espacio de trabajo preparado, completar una tarea visible y mostrar el estado resultante. No debe pedir que se demuestre toda capacidad, explicar cómo hizo el agente la interfaz ni depender de términos que no aparecen en la app.

Una indicación directa crea una secuencia esperada para quien comprueba el candidato. Si el candidato empieza en un lugar inesperado, se detiene en un estado vacío o llega a un resultado distinto, el problema se ve con rapidez. Eso hace que el recurso del README sea más fácil de revisar que una solicitud amplia de un recorrido completo del producto.

Pruebe la ruta después de escribir la indicación. La prueba establece la secuencia que inspeccionar, no una garantía de que la renderización funcionará. Si la tarea depende de una configuración oculta, prepare datos seguros o seleccione una ruta más pequeña. La guía de demo de incidencia de GitHub para agentes de IA usa la misma precisión cuando un compañero necesita inspeccionar una tarea acotada. Un vídeo de demo de agente de codificación puede ofrecer evidencia de navegador relacionada cuando la pregunta trata de un cambio técnico en lugar de la orientación del repositorio.

¿Qué debe comprobar quien escribe el README?

Compruebe si el candidato responde a la pregunta prevista sin depender solo de la narración. Véalo primero sin sonido. El fotograma inicial debe dar suficiente contexto para identificar la tarea, la acción debe ser visible y el resultado no debe depender de una explicación no dicha. Después compare la narración y los subtítulos con la secuencia en pantalla. Una descripción es útil solo cuando coincide con precisión con lo que aparece en pantalla.

Compruebe también si hay material no adecuado para una página de repositorio. Busque datos privados, detalles de clientes, trabajo incompleto, etiquetas engañosas y pantallas no relacionadas. Un archivo terminado no es una aprobación automática. Si el candidato necesita un segundo intento, registre si la ruta, el estado preparado o la indicación causaron el problema, y compruebe la siguiente versión frente a la misma tarea.

Cada cuenta nueva recibe 60 segundos de vídeo una vez, con marca de agua. Después de eso, los vídeos usan tiempo de un plan o de una recarga, y el tiempo solo se usa cuando una renderización sale bien. Esos límites del producto favorecen una historia README concisa. Un lector debe poder entender el resultado del proyecto en una sola pasada en lugar de buscar en una grabación larga el momento que importa.

¿Dónde debe ir la demo dentro del README?

Coloque la demo cerca de la explicación inicial del proyecto, donde pueda confirmar la afirmación que el lector acaba de encontrar. Una frase breve puede indicar el trabajo con el que ayuda la app, y el vídeo puede mostrar la tarea observada. Mantenga la instalación, la configuración y el material de desarrollo separados de la explicación visual para que los lectores elijan la profundidad que necesitan.

Una demo de repositorio no necesita hacer el trabajo de una página de lanzamiento. La guía de demo de automatización de navegador para agentes de IA describe cómo hacer inspeccionable una secuencia seleccionada. La guía de vídeo de demo SaaS ayuda a elegir una tarea relevante para el comprador cuando la app tiene varias historias posibles. La guía de vídeo de demo de producto para README ayuda a decidir cuándo quien lee el repositorio necesita vídeo en lugar de un recurso breve. Para decisiones de grabación manual, GogoScreen frente a Loom y GogoScreen frente a Screen Studio comparan el esfuerzo de preparar un flujo de navegador enfocado.

Empiece en la página de inicio de GogoScreen para revisar el flujo de trabajo de URL e indicación. Consulte precios para conocer los planes y las recargas y lea la política de privacidad antes de que una ruta use una cuenta de demostración. La decisión final corresponde a quien puede confirmar que el texto del README, la tarea visible y el vídeo candidato describen el mismo resultado comprobado.

Aclaraciones

Antes de empezar

¿Qué debe mostrar una demo README para un agente de IA?

Muestre una tarea de navegador que ayude a quien lee el repositorio a entender el proyecto con rapidez. Establezca el contexto inicial, realice la acción importante y muestre el resultado visible después de que una persona haya comprobado la ruta y el candidato.

¿Debe una demo README explicar cómo hizo la app el agente?

Normalmente no. Quien lee el README necesita entender la app que puede ejecutar o inspeccionar. Mantenga el historial de implementación en el registro de desarrollo y use la demo para mostrar un resultado observable en el navegador.

¿Puede una demo README usar una ruta detrás de un inicio de sesión?

Puede usar una ruta de demostración preparada cuando el flujo necesite autenticación. No coloque credenciales en el README ni en el vídeo. La ruta y el candidato siguen necesitando una comprobación humana antes de compartirse.

Pegue una URL, describa un flujo y obtenga un vídeo de demostración de su aplicación web.

Los primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargar el vídeo.

Ver precios Leer las guías