identify-assumptions-existing
por phurynidentify-assumptions-existing te ayuda a poner a prueba una idea de funcionalidad en un producto ya existente, sacando a la luz supuestos arriesgados en torno a Valor, Usabilidad, Viabilidad y Factibilidad. Combina perspectivas de PM, diseñador e ingeniero, además de una mirada de abogado del diablo, para la planificación estratégica y la revisión de riesgos antes de construir.
Esta skill obtiene 78/100, lo que la convierte en una opción sólida para usuarios de directorios que buscan un análisis estructurado de riesgos y supuestos en un producto existente. Tiene un caso de uso claro, un lenguaje de activación fácil de leer y un flujo de trabajo definido que debería ayudar a los agentes a ejecutarla con menos improvisación que un prompt genérico, aunque todavía le faltan recursos de apoyo y ejemplos operativos más profundos.
- Activador y alcance claros para poner a prueba ideas de funcionalidades en un producto existente
- Flujo de trabajo concreto en torno a Valor, Usabilidad, Viabilidad y Factibilidad, con sugerencias de confianza y pruebas
- Sin marcadores de relleno; el contenido del cuerpo es sustancial y lo bastante específico para el uso por agentes
- No incluye archivos de apoyo, referencias ni ejemplos, así que los usuarios deben basarse sobre todo en el texto de `SKILL.md`
- No hay comando de instalación ni recursos auxiliares, lo que limita la incorporación y la guía para casos límite
Descripción general de la skill identify-assumptions-existing
identify-assumptions-existing es una skill de discovery de producto para poner a prueba una idea de funcionalidad en un producto existente antes de comprometerte con trabajo de diseño o desarrollo. Te ayuda a sacar a la luz las suposiciones de riesgo detrás de una propuesta en términos de Valor, Usabilidad, Viabilidad y Factibilidad, usando una mirada interna de abogado del diablo.
Esta skill es ideal para product managers, diseñadores, ingenieros y fundadores que necesitan un mapa rápido de supuestos, no una presentación estratégica pulida. Si estás decidiendo si vale la pena seguir adelante con una funcionalidad, o si intentas detectar los puntos de fallo ocultos en una idea que ya parece prometedora, identify-assumptions-existing encaja muy bien.
Su valor principal está en la calidad de la decisión: lleva la conversación de “suena bien” a “¿qué tiene que ser verdad para que esto funcione?”. Eso la hace especialmente útil para Strategic Planning, la priorización de roadmap y la revisión de riesgos previa a la investigación.
Para qué sirve identify-assumptions-existing
Usa la skill identify-assumptions-existing cuando ya tienes una idea de funcionalidad y necesitas someterla a presión frente a restricciones reales. Está diseñada para revelar en qué punto la idea podría romperse en el mercado, en la experiencia de usuario, en el negocio o en la implementación.
Quién debería instalarla
Instala identify-assumptions-existing si conviertes con frecuencia ideas de producto poco definidas en supuestos que se pueden probar. Es especialmente útil para equipos que quieren una forma repetible de cuestionar propuestas de funcionalidad antes de que se conviertan en tickets, especificaciones o experimentos.
Qué la hace distinta
A diferencia de un prompt genérico de brainstorming, identify-assumptions-existing le pide al modelo pensar desde tres roles: PM, diseñador e ingeniero. Ese encuadre multidisciplinario ayuda a detectar puntos ciegos más rápido y genera pruebas más accionables para cada supuesto.
Cómo usar la skill identify-assumptions-existing
Instálala y actívala
Usa el flujo identify-assumptions-existing install desde el comando del repositorio que aparece en el origen:
npx skills add phuryn/pm-skills --skill identify-assumptions-existing
Después invoca la skill con una idea de funcionalidad para un producto existente. Cuanto más concreto sea tu input, mejor será la lista de supuestos.
Dale a la skill el input correcto
El patrón de identify-assumptions-existing usage funciona mejor cuando incluyes:
- nombre del producto o de la funcionalidad
- segmento de usuario objetivo
- resultado deseado
- la idea de funcionalidad en sí
- cualquier restricción, como plataforma, plazo, cumplimiento normativo o dependencias
Un prompt débil sería: “Analiza mi funcionalidad”.
Un prompt más sólido sería: “Pone a prueba una funcionalidad de exportación de dashboard para administradores financieros de pymes en nuestra app B2B. Objetivo: reducir tickets de soporte. Restricciones: solo web, dos ingenieros, sin nuevo data warehouse.”
Lee el origen en el orden correcto
Para una identify-assumptions-existing guide, empieza por SKILL.md. Si el repositorio se amplía más adelante, revisa también README.md, AGENTS.md, metadata.json y cualquier carpeta rules/, resources/, references/ o scripts/ para obtener contexto adicional. En este repo, SKILL.md es la fuente principal de verdad.
Flujo de trabajo que produce mejores resultados
Un flujo práctico de identify-assumptions-existing usage es:
- Describe el contexto del producto y la idea de funcionalidad.
- Pide supuestos agrupados por Valor, Usabilidad, Viabilidad y Factibilidad.
- Solicita niveles de confianza y una prueba para cada supuesto.
- Usa el resultado para decidir qué validar primero.
Si la usas para Strategic Planning, incluye el segmento de mercado, el objetivo de negocio y las restricciones de lanzamiento para que la skill pueda separar el riesgo estratégico del riesgo de UX o de ingeniería.
Preguntas frecuentes sobre la skill identify-assumptions-existing
¿identify-assumptions-existing es solo para productos existentes?
Sí, ese es su encaje previsto. La skill está afinada para poner a prueba una idea de funcionalidad en un producto existente, no para generar ideación abierta de conceptos desde cero.
¿En qué se diferencia de un prompt normal?
Un prompt normal puede enumerar pros y contras. La skill identify-assumptions-existing va más a fondo al organizar el riesgo en cuatro categorías y preguntar qué podría salir mal, cuánta confianza tienes y cómo comprobarlo. Eso hace que el resultado sea más fácil de convertir en acción.
¿identify-assumptions-existing es apta para principiantes?
Sí, si puedes describir el producto, la audiencia y la funcionalidad en lenguaje sencillo. No necesitas un marco formal de mapeo de supuestos para usarla bien, pero sí hace falta suficiente contexto para que el modelo evalúe los intercambios con realismo.
¿Cuándo no debería usarla?
No uses identify-assumptions-existing si necesitas copy de UX detallado, código de implementación o un plan final de lanzamiento. Es una skill de identificación de riesgos, así que funciona mejor antes de tomar decisiones de desarrollo.
Cómo mejorar la skill identify-assumptions-existing
Aporta un contexto más preciso
La palanca de calidad más importante de identify-assumptions-existing es la especificidad sobre el usuario y el objetivo de negocio. Si solo dices “añadir búsqueda con IA”, la skill tendrá que adivinar demasiado. Si dices “añadir búsqueda con IA para agentes de soporte para reducir el tiempo de respuesta en tickets repetidos”, los supuestos serán mucho más útiles.
Pide pruebas, no solo preocupaciones
La fuente indica que la skill debe incluir qué podría salir mal y cómo probarlo, así que no te quedes en los riesgos. Pide ideas de validación ligeras como entrevistas, pruebas con prototipos, revisión de logs o un dogfood interno. Eso convierte el resultado en un artefacto de planificación, no solo en una crítica.
Separa el riesgo de producto del riesgo de entrega
Las salidas más útiles de identify-assumptions-existing suelen distinguir entre valor para el usuario, fricción de adopción, restricciones de negocio y factibilidad técnica. Si tu prompt mezcla todo eso en una sola petición vaga, la respuesta será menos útil para tomar decisiones. Expón las restricciones de forma explícita para que la skill pueda priorizar primero los supuestos más peligrosos.
Itera después de la primera pasada
Usa el primer resultado para acotar el alcance y luego vuelve a ejecutar la skill con una porción más enfocada de la funcionalidad. Por ejemplo, si la primera pasada muestra riesgo de usabilidad e integración, vuelve a pedir solo el flujo de onboarding o solo la dependencia de sincronización de datos. Muchas veces esa es la forma más rápida de afinar una conversación de Strategic Planning.