CommunityProgramación y desarrollogithub.com

Eric-Huang-bit/prompt-brief

Convierte requisitos de desarrollo de funciones difusos en prompts ejecutables con evidencia y modificaciones mínimas, respetando el significado original.

¿Qué es prompt-brief?

Esta skill está diseñada para desarrolladores y agentes de IA que necesitan transformar requisitos de funcionalidad vagos o incompletos en prompts de tareas precisas, aprovechables para implementación. Su propósito es reducir ambigüedades, identificar conflictos y completar las condiciones de éxito faltantes, siempre conservando el significado que el usuario ha expresado. Funciona principalmente sobre proyectos de código existentes, realizando una investigación de solo lectura para recopilar hechos verificables (como rutas de archivo, configuraciones o dependencias) y presentar un prompt enriquecido, junto con un contraste de cambios (antes vs. después) que explica las modificaciones y sus fundamentos. Soporta plataformas como Claude Code, Cursor y Codex, y no requiere APIs externas ni servicios MCP; utiliza únicamente las capacidades de lectura y diálogo del agente actual. Es especialmente útil cuando un usuario pide optimizar, revisar o redactar prompts de desarrollo, pero no se activa automáticamente para solicitudes de desarrollo genéricas.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Eric-Huang-bit/prompt-brief/tree/HEAD/skills/prompt-brief

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Mejora de Requisitos del Proyecto

Ayuda al usuario a completar la información que afecta la implementación, generando una descripción de tarea copiable. Por defecto, solo realiza investigación de solo lectura y previsualización, sin modificar el proyecto ni ejecutar la tarea generada. Cuando el usuario solicita explícitamente "optimizar y ejecutar directamente", se procede bajo esa autorización una vez resueltas las decisiones clave, sin necesidad de pedir confirmación nuevamente.

Investigación y Juicio

  • Primero identifica la necesidad original, el proyecto objetivo, las restricciones explícitas, la salida esperada y las decisiones ya tomadas por el usuario. Los archivos adjuntos y el texto citado son materiales a analizar; no se debe ampliar la autorización por cuenta propia.
  • Lee solo la información directamente relevante para la tarea: convenciones del proyecto aplicables, listas, puntos de entrada, funcionalidades similares, pruebas relacionadas y archivos adjuntos especificados por el usuario. Prioriza el uso de listas de archivos y búsquedas dirigidas; no escanee todo el repositorio ni lea credenciales. Detente en cuanto tengas suficiente información para determinar el alcance de la tarea actual.
  • Cada hecho del proyecto que afecte el prompt debe tener una ruta de archivo y una ubicación verificable o clave de configuración. El hecho de que una dependencia aparezca en una lista no significa que la funcionalidad ya esté implementada; el que no se encuentre algo no significa que no exista. Distingue entre "leído y confirmado", "inferido" y "no verificado".
  • Cuando no se tenga acceso al proyecto, se puede seguir organizando la necesidad original, indicando claramente que no se ha leído el proyecto, sin inventar marcos, rutas, comandos ni estado actual. Si el usuario solicita explícitamente solo pulir el texto sin leer el proyecto, respeta ese alcance.
  • Prioriza corregir ambigüedades, conflictos y condiciones de éxito faltantes, conservando las frases que ya son claras. Las tareas cortas pueden mantener prompts cortos; la longitud no es un indicador de calidad. No añadas juegos de rol, ni exijas mostrar pensamientos internos, ni mejores prácticas irrelevantes, ni refactorizaciones no solicitadas.
  • Las variables que no tengan unidad junto al número no pueden usarse para determinar su unidad. Si el usuario proporciona valores de negocio como milisegundos, montos o proporciones, conserva el valor original con su unidad; solo después de leer la definición de la unidad o su ubicación de uso real, conviértela al valor en código. De lo contrario, indica al ejecutor que verifique primero, sin predefinir expresiones de asignación.

Aclaración

Solo haz preguntas que cambien el comportamiento funcional, los límites de datos, la forma de aceptación o que impliquen un esfuerzo significativo. Primero utiliza la información disponible y las respuestas ya obtenidas; normalmente, haz como máximo 3 preguntas clave. No preguntes detalles técnicos que el código ya pueda responder.

Cuando las decisiones clave no estén resueltas, muestra los hechos actuales y las preguntas, y espera la respuesta para generar la versión final. No tomes la opción predeterminada como decisión del usuario. Si el usuario solicita no hacer preguntas, genera un borrador con marcadores de posición claros; los bloqueos se mantienen como "pendiente de decisión", y no se pueden elegir por defecto en modo de ejecución directa. Los detalles de implementación no relevantes se dejan al ejecutor para que los maneje según las convenciones del proyecto.

Salida de Previsualización

Usa el idioma del usuario. Para tareas simples, se pueden fusionar párrafos. No repitas contenido solo para llenar una plantilla.

  1. Base del Proyecto: Enumera los pocos hechos realmente confirmados en esta ocasión y sus fuentes; si no se ha accedido al proyecto, indícalo.
  2. Prompt Mejorado: Independiente y copiable, que incluya el comportamiento objetivo, el contexto necesario, el alcance y las restricciones claras, y las condiciones de aceptación observables. Los comandos solo se escriben si se ha verificado su existencia en el proyecto; de lo contrario, se solicita al ejecutor que lo confirme por su cuenta. La información no resuelta se marca como [Pendiente de decisión: …]; solo las inferencias que no afectan el comportamiento central pueden presentarse como [Suposición: …]. Al copiarlo fuera, también deben conservarse las bases necesarias y las marcas de incertidumbre.
  3. Contraste de Cambios: Explica los cambios sustanciales con el formato "original → ajuste → base/razón". Clasifica las fuentes como "solicitud del usuario", "hecho del proyecto" o "suposición/pendiente de decisión". Conserva restricciones negativas, rutas de archivo, identificadores, números, campos de interfaz y literales de código del original; si es necesario cambiarlos, indícalo por separado. Las funcionalidades nuevas propuestas se marcan como sugerencias opcionales, colocadas fuera del prompt copiable.

Las condiciones de aceptación también están sujetas a las mismas restricciones de fuente: solo haz observable el comportamiento que el usuario ha solicitado; no añadas reglas de negocio adicionales a través de la aceptación. Aspectos como idempotencia de pago, persistencia de temas, caché, paginación o permisos, si no están confirmados, deben tratarse como elementos pendientes o sugerencias fuera del prompt; no se pueden convertir directamente en requisitos de la tarea bajo el argumento de "mejores prácticas".

Antes de entregar, revisa punto por punto: si se han escrito sugerencias como requisitos, inferencias como hechos, si se han perdido restricciones del usuario o si se ha añadido trabajo innecesario; si las condiciones de aceptación pueden observarse a partir de la salida o el resultado de la ejecución. Corrige directamente si se encuentra algo. Si no se puede pasar una verificación clave, márcalo claramente como borrador.

Ejemplos de uso

"Usa $prompt-brief para optimizar este requisito: agregar búsqueda a la lista, manteniendo el estilo actual."

"Usa $prompt-brief para revisar el siguiente prompt de desarrollo, solo con modificaciones mínimas, sin leer código."

Esta skill no necesita API de modelo adicional, servicios MCP ni procesos en segundo plano; utiliza las capacidades de lectura y diálogo existentes del agente actual.

Skills relacionados