Por qué está escrito así
La razón por la que se necesita un buen prompt para el README es que los creadores suelen escribir pensando en su propio entorno. Las herramientas ya instaladas, los archivos de entorno ya configurados y las bases de datos ya activas resultan invisibles para ellos. Por eso, cuando otra persona intenta ejecutarlo, se queda atascada en el segundo comando.
El bloque de contexto fuerza el cambio de perspectiva. Al fijar que es "un desarrollador que lo clona por primera vez" y que "no conoce los sistemas internos", la IA se ve obligada a preguntar por los pasos omitidos o a marcarlos con marcadores de posición.
El orden del formato sigue la secuencia real con la que alguien explora un repositorio: entender qué es, ver cómo luce, verificar requisitos, instalar y ejecutar. Dejar las variables de entorno y los problemas frecuentes hacia el final responde a que suelen necesitarse a partir del segundo intento. Pedir explicaciones junto a cada comando evita que la gente copie y pegue a ciegas sin entender lo que ejecuta.
El último párrafo asegura recibir primero el índice antes de redactar todo el texto. Si se pide el documento completo de una sola vez, suele generar un texto inflado con insignias inventadas y funciones inexistentes, donde corregir toma más tiempo que borrar. Validar el esquema permite podar secciones innecesarias y afinar el resultado. También sirve como filtro para no subir a GitHub un texto generado por IA sin revisión.
La instrucción de "dejar marcado como (Completar)" complementa esto. Si no se permiten huecos en blanco, la IA inventa datos plausibles. Con marcas visibles, queda claro qué falta añadir y la documentación se mantiene honesta.
¿Términos desconocidos? Consulta Aha AI: context-window, output-format
Comparado con un mal ejemplo
Hazme un README para mi proyecto. Uso Next.js y PostgreSQL.
Generará un documento de apariencia atractiva al instante, pero la mitad será inventada: scripts de npm inexistentes, variables de entorno que no se usan, y badges o licencias sin enlace real. Además, faltarán pasos cruciales como levantar la base de datos local porque nunca se los mencionaste. Limpiar y corregir eso toma más tiempo que escribirlo desde cero.
Variaciones
Para revisar un README existente
A continuación está el README actual de {{nombre del proyecto}}. Identifica los puntos donde alguien que clona este repositorio por primera vez podría quedarse bloqueado al intentar ejecutarlo. No reescribas el documento completo; entrégame solo una tabla con las columnas "Punto de bloqueo · Por qué ocurre · Cómo solucionarlo".
""" {{método de ejecución}} """
Útil cuando ya existe documentación pero las nuevas incorporaciones siempre hacen las mismas preguntas. Pedir que no reescriba todo ayuda a conservar el contenido previo y detectar solo los vacíos.
Para onboarding de nuevos integrantes
Escribe una guía de incorporación para un desarrollador junior que asumirá el proyecto {{nombre del proyecto}} por primera vez. De toda la {{pila tecnológica}}, destaca únicamente lo que realmente necesita dominar para este proyecto y divide el texto en tres secciones: "Tareas del primer día · Qué aprender la primera semana · Dónde consultar si te bloqueas". Deja marcado como "(Confirmar con responsable)" cualquier elemento que requiera cuentas o permisos internos.
""" {{método de ejecución}} """
Un README para un repositorio público y un documento de traspaso interno tienen objetivos distintos. Para un nuevo integrante, el orden y el alcance del aprendizaje son lo prioritario.
Notas por modelo
Antes de subir el README definitivo, clona el repositorio en una carpeta limpia y sigue los pasos tal como están escritos. Solo así verás los pasos que hayan quedado fuera.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos