webflow/webflow-skills

Aplicaciones Cloud de Webflow

Usa data_apps_tool para crear aplicaciones con fuente en GitHub, responder preguntas operativas, y gestionar entornos para aplicaciones Cloud de Webflow. Comienza desde el resultado deseado por el usuario, recopila solo la evidencia necesaria y distingue observaciones de conclusiones.

Usa el skill webflow-cli:cloud cuando la tarea requiera la creación o implementación de aplicaciones desde CLI/fuente local, o crear o actualizar variables de entorno. El resultado de la compilación del lado del cliente no se envía a Webflow y no se puede recuperar a través de MCP.

Instrucciones

1. Establecer el alcance

Usa la conexión MCP de Webflow establecida por la solicitud del usuario o el contexto de la tarea existente. Si solo hay una conexión activa, úsala sin preguntar al usuario que elija o reconfirme una región. Si hay múltiples conexiones activas y el objetivo deseado sigue siendo ambiguo, pide al usuario que desambigüe antes de proceder con operaciones que dependen del objetivo. No cambies de región para recuperarte de errores de recursos faltantes o de acceso.

Antes de pasar una aplicación o entorno MCP existente al CLI para escrituras de configuración o implementación, compara sus regiones configuradas. Si difieren, no asumas que ninguna es correcta ni redirijas silenciosamente ninguna herramienta. Resuelve el objetivo deseado a partir del contexto explícito de la tarea; si esto no resuelve el conflicto, pregunta al usuario. Pausa las mutaciones dependientes hasta que se resuelva el conflicto.

Una vez establecida la región deseada, verifica que el CLI pueda leer los IDs exactos de la aplicación y el entorno MCP, y lleva esa región y esos IDs explícitamente a mutaciones posteriores. El estado de inicio de sesión o una etiqueta de región por sí solos no son suficientes. Si la verificación falla, informa del fallo sin inferir su causa y pausa las mutaciones dependientes. Continúa con el trabajo independiente cuyo objetivo esté establecido.

1. Llama a webflow_guide_tool antes que cualquier otra herramienta MCP de Webflow. La guía en vivo y los esquemas de acción son autoritativos para los argumentos y respuestas actuales.
2. Usa las herramientas MCP de Webflow para operaciones de Webflow, excepto la transferencia explícita al CLI para valores de variables de entorno. Nunca llames directamente a las APIs de Webflow.
3. Incluye el parámetro context requerido en cada llamada a la herramienta. Escribe 15-25 palabras en tercera persona.
4. Enruta según la capacidad que requiera la tarea:
   • Usa data_apps_tool para crear aplicaciones con fuente en GitHub; inspeccionar aplicaciones, entornos, dominios, registros de implementación, registros y metadatos de variables; gestionar fuentes de GitHub y entornos; y poner en cola implementaciones de GitHub.
   • Usa data_variable_tool para variables de color, tamaño, fuente y CSS del Diseñador.
   • Usa webflow-cli:cloud para aplicaciones CLI/fuente local, compilaciones e implementaciones locales, o crear y actualizar valores de variables de entorno.
5. Si data_apps_tool no está disponible, informa que la capacidad MCP de aplicaciones Cloud no está habilitada. No la evites con una solicitud directa a la API.

Nunca pidas al usuario que pegue un valor de variable de entorno o secreto en el chat. Para una creación o actualización, delega a webflow-cli:cloud y requiere un prompt oculto, stdin o un archivo protegido. Nunca pases un secreto como argumento posicional.

2. Resolver el objetivo

Descubre los identificadores en este orden:

list_apps -> app_id
list_environments(app_id) -> env_id
list_deployments(app_id, env_id) -> deployment_id

Los nombres de las aplicaciones son únicos solo dentro de un sitio, así que resuelve una aplicación nombrada con site_id + name. Si múltiples recursos coinciden, presenta los metadatos distintivos y requiere que el usuario seleccione uno antes de cualquier mutación. Usa la guía en vivo para los mecanismos de filtro, paginación, cursor y lotes de acciones.

3. Sigue la historia de usuario coincidente

Crear una aplicación con fuente en GitHub

1. Establece el nombre de la aplicación, la URL canónica del repositorio de GitHub, la rama, la descripción opcional y si es independiente o está adjunta a un sitio existente.
2. Para una aplicación adjunta a un sitio, resuelve el ID del sitio. Omite site_id para una aplicación independiente.
3. Aplica el contrato de montaje antes de la vista previa:
   • Una aplicación independiente siempre se monta en /; omite mount o usa /.
   • Una aplicación adjunta a un sitio tiene como valor predeterminado /app, rechaza / y requiere un montaje válido no raíz al anular el valor predeterminado.
4. Explica que la creación independiente requiere un token de usuario con ámbito de espacio de trabajo. Webflow deriva la instalación de GitHub y valida el acceso al repositorio; no solicites un ID de instalación.
5. Llama a create_app con su ejecución de prueba predeterminada. Muestra el repositorio, la rama, el adjunto, el sitio cuando corresponda, el montaje y el intento de implementación inicial.
6. Requiere confirm. Inmediatamente después de la confirmación y antes de la ejecución, registra la hora de inicio y genera una idempotency_key estable; ejecuta con dry_run: false, luego registra la hora de finalización. Reutiliza esa clave solo para reintentos exactos de esta creación.
7. Trata la creación y la implementación inicial como resultados separados. Que se devuelva una aplicación significa que la creación fue exitosa incluso si deployStatus es skipped o failed. Para triggered, inspecciona el entorno y la implementación; para skipped, verifica la rama o envía un commit; para failed, conserva la aplicación e inspecciona o reintenta la implementación por separado.
8. Si la aplicación o el resultado no se puede leer, concilia antes de reintentar:
   • Para una aplicación adjunta a un sitio, recopila candidatos con site_id + name; para una aplicación independiente, recopila candidatos por nombre.
   • En ambos casos, compara el nombre, sourceUrl y createdAt de cada candidato con el repositorio solicitado y la ventana de ejecución registrada.
   • Continúa a entornos e implementaciones solo cuando exactamente un candidato coincida. No reintentes mientras la aplicación creada siga siendo ambigua.
9. Nunca elimines una aplicación creada automáticamente porque la implementación falló. No trates un enlace al panel de control de la implementación inicial como la URL pública del entorno.

¿Qué aplicación y entorno estoy viendo?

1. Usa list_apps para encontrar la aplicación y get_app para sus metadatos, incluyendo sourceUrl y siteAttached.
2. Usa list_environments para informar la rama, el montaje, publicUrl y el estado de la última implementación. Si publicUrl es nulo, informa que no hay una dirección de entorno orientada al usuario disponible; no construyas una.
3. Usa get_app_domains cuando el usuario pregunte dónde es accesible la aplicación.
4. Explica que los resultados de dominio personalizado excluyen el nombre de host predeterminado *.webflow.io. Los dominios para una aplicación adjunta a un sitio de Webflow normal pueden pertenecer al sitio principal y ser compartidos por aplicaciones hermanas.

¿Qué está implementado y está en buen estado?

1. Usa list_environments para el estado de la última implementación del entorno.
2. Usa list_deployments, del más nuevo al más antiguo, luego get_deployment para la línea de tiempo detallada y los metadatos de versión de la implementación seleccionada.
3. Trata starting, building y deploying como estados activos. Informa cualquier otro estado exactamente en lugar de adivinar su significado.
4. Una fase fallida establece buildFailedAt o deployFailedAt mientras su marca de tiempo de finalización coincidente permanece nula. Una marca de tiempo de finalización nula por sí sola no prueba que la fase aún se esté ejecutando.
5. Informa lo que es observable: aplicación y entorno seleccionados, estado de implementación, versión o metadatos de commit si se devuelven, marcas de tiempo de fase y lagunas de evidencia.

¿Por qué falló la implementación?

1. Obtén la implementación con get_deployment e identifica la fase fallida a partir de su estado y marcas de tiempo.
2. Llama a get_build_logs solo cuando logsAvailable sea verdadero. Comienza con una ventana since estrecha o un filtro q, luego amplía solo si es necesario.
3. Pagina hasta que nextCursor sea nulo cuando se requiera un resultado completo.
4. Trata logsAvailable como una señal de retención y recuperación, no como prueba de que cada fase produjo entradas de registro.
5. Trata un resultado vacío como "no hay registros recuperables del lado del servidor que coincidan", no como prueba de que la compilación fue exitosa o no produjo errores.
6. La salida de compilación producida en la máquina de un usuario está fuera de MCP. Menciona esto solo cuando el usuario diga que la implementación se compiló con el CLI; dirígelos a la salida del CLI original para fallos de compilación local.
7. Informa la fase fallida, las marcas de tiempo relevantes, la evidencia útil más pequeña, la causa inferida y cualquier incertidumbre. No te limites a repetir los registros sin procesar.

¿Por qué está fallando la aplicación en ejecución?

1. Resuelve el entorno exacto y llama a get_runtime_logs.
2. Limita por since y q antes de recuperar una ventana amplia. Página completamente cuando la conclusión dependa de la ausencia.
3. Los registros de tiempo de ejecución pueden no estar disponibles debido a la retención. Trata un resultado vacío como que no hay registros recuperables e informa la limitación.
4. Correlaciona la evidencia de tiempo de ejecución con el registro de implementación más reciente cuando sea útil, pero no reclames causalidad solo por la sincronización.
5. Informa el patrón de error observado, el intervalo afectado, la causa probable, la evidencia y las limitaciones.

¿Está presente la configuración requerida?

1. Establece el conjunto de claves requeridas a partir de una fuente autorizada: una lista de claves proporcionada por el usuario, un esquema de configuración del proyecto o un requisito documentado, o un entorno de referencia que el usuario designe explícitamente como completo.
2. Si la fuente es un archivo protegido que contiene valores, realiza una extracción determinista solo de claves localmente y emite solo los nombres de las claves. Nunca abras la fuente a través de una lectura visible por el modelo ni incluyas sus valores en el chat o la salida de la herramienta.
3. Obtén una designación de secreto autorizada para cada clave requerida del usuario, un esquema del proyecto o un requisito documentado, o un entorno de referencia designado explícitamente como autorizado para el secreto. Un archivo .env o una lista de claves simples establece solo nombres; nunca infieras el secreto a partir de los nombres de las claves.
4. Resuelve el entorno, llama a list_variables y compara sus claves y metadatos de secreto con los requisitos establecidos. Prueba lo que está configurado, no lo que se requiere. Agota la paginación antes de concluir que falta una clave.
5. Informa solo las claves y los metadatos. Las entradas secretas tienen isSecret: true y ningún valor; falta un valor secreto es esperado.
6. Si el conjunto requerido o cualquier designación de secreto no está resuelto, detente antes de una mutación del CLI o una implementación dependiente a menos que el usuario establezca explícitamente que no se requiere configuración.
7. Para claves faltantes o mal clasificadas, enruta a webflow-cli:cloud sin solicitar valores en el chat. Después de la escritura, verifica las claves requeridas y el secreto con list_variables. Si falla parcialmente, informa las claves fallidas sin valores y detente antes de la implementación; conserva las claves exitosas y el entorno.

¿Por qué este entorno está sirviendo la rama o ruta incorrecta?

1. Resuelve el entorno exacto e informa su rama actual, montaje, publicUrl y estado de la última implementación. Informa un publicUrl nulo sin construir una dirección.
2. Compara la rama y el montaje actuales con la asignación deseada por el usuario. Si la solicitud es solo de diagnóstico, detente después de informar el desajuste.
3. Si la corrección cambia el montaje, llama a get_app y usa siteAttached:/ es válido solo cuando es falso; una aplicación adjunta a un sitio requiere un montaje no raíz. No infieras el adjunto a partir de siteId.
4. Para una corrección, muestra la asignación exacta antes y después. Explica que update_environment es inmediato, no tiene ejecución de prueba y no implementa código.
5. Requiere confirm, llama a update_environment una vez e informa el entorno devuelto, publicUrl y mountRefreshStatus.
6. Para un resultado ilegible o incierto, localiza el env_id original. Si usas la nueva rama esperada como filtro, acepta un entorno devuelto solo cuando su ID sea igual a ese env_id original, luego compara su rama y montaje con los valores solicitados. Un ID diferente o ningún objetivo original único coincidente es ambiguo: no continúes ni reintentes. Nunca reutilices el filtro de rama anterior después de una actualización que cambie la rama.
7. Una actualización de montaje fallida o desconocida no significa que la actualización del entorno se haya revertido. Informa el enrutamiento como incierto y no reintentes solo porque la actualización falló.
8. Si la rama cambió y el usuario quiere que su código se implemente, trata trigger_deployment como una mutación separada con vista previa y confirmación.

Crear un entorno aislado para una rama e implementarlo

1. Resuelve la aplicación existente, llama a get_app y valida el montaje propuesto con siteAttached antes de previsualizar la mutación.
2. Pagina a través de list_environments para verificar si la rama o montaje solicitado ya está en uso.
3. Muestra la rama y el montaje propuestos. Explica que create_environment es inmediato, no tiene ejecución de prueba y crea una asignación sin implementar código.
4. Genera una idempotency_key estable, requiere confirm y llama a create_environment. Reutiliza esa clave solo para reintentos exactos.
5. Informa el entorno devuelto, publicUrl y mountRefreshStatus. Si el resultado es incierto, busca la rama esperada y compara el ID del entorno, la rama y el montaje; usa un ID devuelto para distinguir creaciones concurrentes. No reintentes mientras el entorno creado siga siendo ambiguo.
6. Una actualización fallida significa que la creación fue exitosa pero el enrutamiento puede estar incompleto. No reintentes la creación ni elimines el entorno automáticamente.
7. Antes de implementar este nuevo entorno, sigue "¿Está presente la configuración requerida?" como una puerta obligatoria. Continúa solo después de que los requisitos y el secreto estén verificados, o el usuario establezca explícitamente que no se requiere ninguno. Luego usa el flujo de trabajo de implementación a continuación para la vista previa, confirmación, atribución y monitoreo.

¿Se puede reintentar, revertir o reconstruir esta implementación a partir del HEAD de la rama?

Usa la ejecución de prueba predeterminada de la mutación como verificación de capacidad. No infieras la elegibilidad a partir de registros faltantes, metadatos de aplicación o metadatos de implementación.

Para una nueva implementación desde la rama conectada o un commit exacto anterior:

1. Resuelve el entorno. Para un reintento o reversión, también resuelve la implementación anterior exacta.
2. Realiza el descubrimiento de configuración solo cuando el usuario lo solicite, la evidencia de implementación indique variables faltantes o mal clasificadas, el commit seleccionado tenga requisitos de configuración documentados, o el servidor rechace la implementación por configuración.

...