shape
por pbakausshape es una skill de UX/UI centrada en la planificación: realiza una entrevista de descubrimiento y convierte las respuestas en un brief de diseño antes de escribir código. Úsala con /impeccable para aclarar objetivos de usuario, restricciones, estados y la dirección de implementación en UI Design.
Esta skill obtiene una puntuación de 78/100, lo que la convierte en una candidata sólida para el directorio: ofrece a los agentes un disparador claro, un propósito definido antes de programar y un resultado estructurado, aunque quienes la adopten deben contar con un flujo basado solo en documentos que depende de otra skill para el contexto completo y la ejecución posterior.
- Disparador y alcance claros: está pensada explícitamente para dar forma a una funcionalidad antes de escribir código, con `user-invocable: true` y una pista de argumento para la funcionalidad.
- Resultado útil en la práctica: la skill promete un brief de diseño concreto que puede guiar la implementación y entregarse a otras skills.
- Buen enfoque procedimental: define una preparación obligatoria, una fase de entrevista de descubrimiento y restricciones como no escribir código durante el descubrimiento.
- Dependencia fuerte de `/impeccable`: la skill exige invocar esa skill principal y, posiblemente, `/impeccable teach`, lo que limita su utilidad por sí sola.
- No se incluyen archivos de apoyo, ejemplos ni instrucciones de instalación, por lo que los usuarios deben deducir el flujo exacto de la entrevista y el formato del brief únicamente a partir del texto.
Descripción general de shape skill
Qué hace shape
shape skill es un flujo de trabajo de UX/UI centrado primero en la planificación para definir una funcionalidad antes de escribir cualquier código. En lugar de lanzarse directamente a layouts o componentes, realiza una entrevista de descubrimiento estructurada y convierte las respuestas en un design brief. Por eso resulta útil cuando tu equipo sabe en términos generales qué quiere construir, pero todavía no ha aclarado los objetivos del usuario, las restricciones, los estados, los casos límite o la dirección de implementación.
Quién debería instalar shape skill
El mejor encaje de shape skill son equipos con mentalidad de producto, diseñadores, frontend engineers y equipos asistidos por IA que quieren tomar mejores decisiones antes de prototipar. Es especialmente relevante para shape for UI Design cuando una funcionalidad aún es ambigua: nuevos flujos, dashboards, formularios, onboarding, ajustes o cualquier interfaz en la que “simplemente generar una UI” probablemente no capture el trabajo real que el usuario necesita resolver.
Por qué la gente elige shape frente a un prompt genérico
Un prompt normal suele producir mockups instantáneos o ideas de componentes. shape hace lo contrario a propósito: ralentiza el proceso para obligar a recopilar contexto primero y después crear un design brief que puedas entregar más tarde a skills de implementación. El repo deja claro su alcance: esto es planificación de diseño, no coding. Ese límite es valioso si buscas menos sugerencias superficiales de UI y decisiones de producto más sólidas y defendibles.
Cómo usar shape skill
Contexto de instalación y requisito previo obligatorio
Instala la skill desde el repositorio pbakaus/impeccable usando tu flujo de skills, por ejemplo:
npx skills add pbakaus/impeccable --skill shape
El detalle de adopción más importante es el requisito previo indicado en SKILL.md: shape requires /impeccable first. La skill indica que debes invocar /impeccable, seguir su Context Gathering Protocol y, si todavía no existe contexto de diseño, ejecutar /impeccable teach antes de usar shape skill. Si te saltas ese paso, estarás usando la skill fuera del flujo para el que fue diseñada.
Qué entrada necesita shape para funcionar bien
La pista del argumento es [feature to shape], pero un nombre de funcionalidad en una sola línea normalmente no basta. Un uso más sólido de shape skill empieza con:
- el objetivo de la funcionalidad
- el usuario o rol objetivo
- el flujo actual o el problema existente
- los criterios de éxito
- restricciones duras como plataforma, permisos, compliance o design system existente
- casos límite conocidos o aspectos fuera de alcance
Una entrada débil sería: Shape a notifications page.
Una entrada más fuerte sería: Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.
Flujo práctico y archivos que conviene leer primero
Lee primero SKILL.md y tómalo como el contrato operativo. Este snapshot del repositorio solo expone ese archivo, así que gran parte del valor está en seguir bien su secuencia:
- Recopilar contexto de diseño mediante
/impeccable. - Usar shape en la fase de planificación, no de implementación.
- Dejar que conduzca la entrevista de descubrimiento.
- Convertir la entrevista en un design brief.
- Entregar ese brief a
/impeccable craft,/impeccableu otro flujo de implementación.
Esto importa porque la skill está optimizada para reducir las suposiciones antes de empezar el trabajo de UI, no para generar pantallas pulidas de una sola vez.
Patrón de prompt para obtener mejores resultados con shape skill
Para invocar shape skill de forma eficaz, pide explícitamente tanto la entrevista como el entregable final. Estructura de ejemplo:
- funcionalidad a definir
- quién es el usuario principal
- problema actual
- restricciones imprescindibles
- qué decisiones quieres que el brief deje resueltas
Ejemplo:
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.
Esto funciona mejor que “design a UI for X” porque le da a la skill espacio para hacer preguntas de aclaración antes de fijar una dirección.
Preguntas frecuentes sobre shape skill
¿shape skill sirve para programar o para planificar?
shape skill es para planificación. El repositorio lo dice de forma explícita: no escribe código. Su salida es un design brief que guía la implementación posterior. Si quieres código inmediato, este no es el mejor punto de partida; si quieres tomar mejores decisiones de producto y UI antes, sí encaja bien.
¿Cuándo es mejor shape que un prompting normal?
Usa shape cuando la funcionalidad esté poco definida, implique riesgo, sea visible para usuarios o probablemente tenga estados y tradeoffs complejos. Un prompt genérico puede ser más rápido para un mockup desechable. shape es mejor cuando necesitas razonamiento sobre flujo de trabajo, necesidades del usuario, restricciones y calidad del handoff.
¿shape es adecuado para principiantes?
Sí, con un matiz: incluso los principiantes necesitan suficiente contexto de producto para responder bien la entrevista de descubrimiento. La skill aporta estructura, pero no puede inventar tus usuarios, tus restricciones ni tus métricas de éxito. Si estás empezando en UX planning, su enfoque guiado por entrevista resulta especialmente útil porque saca a la luz las preguntas que de todos modos deberías haber respondido.
¿Cuándo no debería usar shape for UI Design?
Omite shape for UI Design cuando el problema ya esté totalmente especificado, cuando solo necesites un ajuste visual mínimo o cuando la tarea sea puramente técnica y no trate sobre interacción de usuario. También encaja mal si no estás dispuesto a seguir el paso previo de recopilación de contexto, porque la skill depende de esa base.
Cómo mejorar shape skill
Dale a shape mejores entradas de planificación
La mayor palanca de calidad está en la calidad de la entrada. En shape skill, mejores entradas significan algo más que nombres de funcionalidades. Incluye tipo de usuario, frecuencia de la tarea, coste del fallo, patrones existentes, reglas de negocio y qué debe quedar fuera de alcance. La skill seguirá entrevistándote, pero un contexto inicial más rico produce un brief más preciso y menos recomendaciones genéricas.
Evita el principal modo de fallo: soluciones prematuras
La advertencia más importante del repo es no tomar decisiones de diseño demasiado pronto. Un mal uso habitual de shape skill es pedir pantallas, cards, tabs o layouts antes de aclarar el problema del usuario. Si ves que la conversación salta demasiado rápido a patrones de interfaz, redirígela: pide primero necesidades no cubiertas del usuario, flujo de tareas, estados, tradeoffs y restricciones.
Itera sobre el design brief, no solo sobre el prompt
Después de la primera pasada, mejora el brief poniendo a prueba las decisiones poco claras:
- ¿Cuál es el objetivo principal del usuario?
- ¿Qué estados faltan?
- ¿Qué supuestos necesitan validación?
- ¿Qué se excluye intencionadamente de v1?
- ¿Qué podría volver ambigua la implementación?
Ese tipo de iteración mejora el uso de shape skill mucho más que pedir repetidamente “a better UI”.
Combina shape con la ejecución posterior
La forma práctica de aumentar el valor de shape install es tratarlo como la primera etapa de una cadena. Usa shape para crear el brief y luego pásalo a /impeccable craft o a otra skill de implementación. Cuanto mejor sea tu artefacto de handoff, más probable será que el código o la generación de diseño posterior se mantengan alineados con las necesidades del usuario, en lugar de desviarse hacia una UI plausible a primera vista pero débil en la práctica.