Taller de Prompts
Por qué está escrito así
Toca un bloque para ver su párrafo
Quiero crear el README para el repositorio {{nombre del proyecto}}. Este proyecto está desarrollado con {{pila tecnológica}} y el lector objetivo es un desarrollador que clona este repositorio por primera vez hoy para intentar ejecutarlo en su máquina local. No conoce el contexto de nuestro equipo ni nuestros sistemas internos.
Escribe un borrador del README. Reorganiza el método de ejecución que incluyo abajo en un orden secuencial claro, de modo que cualquiera pueda seguirlo de arriba abajo sin perderse.
Formato: Organiza el documento con los siguientes subtítulos: "Descripción breve · Captura o demo visual · Requisitos previos · Instalación · Ejecución · Variables de entorno · Estructura de carpetas · Problemas comunes (FAQ)". Muestra cada comando en una línea independiente y añade una breve explicación al lado indicando qué hace.
No inventes comandos, URLs, versiones ni insignias (badges) que yo no haya especificado. Si falta información en algún punto, déjalo marcado como "(Completar: qué se necesita)".
No escribas todo el contenido de golpe. Primero, muéstrame solo el esquema con los subtítulos y una sola línea que resuma lo que irá en cada sección. Cuando te responda "Adelante", redacta el cuerpo completo y, a partir de ahí, ajusta solo las secciones que yo te indique.
Método de ejecución: """ {{método de ejecución}} """
- Información Lo que la IA necesita saber ×2
- Trabajo Qué hacer y cómo ×1
- Resultado Qué recibes y con qué forma ×2
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.
Leer la explicación completa · 4 párrafos
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
Ú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.
Ver prompt
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}} """
Para onboarding de nuevos integrantes
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.
Ver prompt
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}} """
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.
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos