webflow/webflow-skills

Aplicativos Webflow Cloud

Use a data_apps_tool para criar aplicativos com origem no GitHub, responder a perguntas operacionais e gerenciar ambientes para aplicativos Webflow Cloud. Comece pelo resultado desejado do usuário, colete apenas as evidências necessárias e distinga observações de conclusões.

Use o skill webflow-cli:cloud quando a tarefa exigir criação ou implantação de aplicativo com origem CLI/local, ou criar ou atualizar variáveis de ambiente. A saída de build do lado do cliente não é enviada para o Webflow e não pode ser recuperada através do MCP.

Instruções

1. Estabeleça o escopo

Use a conexão MCP do Webflow estabelecida pela solicitação do usuário ou pelo contexto da tarefa existente. Se apenas uma conexão estiver ativa, use-a sem pedir ao usuário para escolher ou re-confirmar uma região. Se várias conexões estiverem ativas e o destino pretendido permanecer ambíguo, peça ao usuário para desambiguar antes de prosseguir com operações dependentes do destino. Não alterne regiões para se recuperar de recursos ausentes ou erros de acesso.

Antes de entregar um aplicativo ou ambiente MCP existente ao CLI para gravações de configuração ou implantação, compare suas regiões configuradas. Se elas diferirem, não assuma que nenhuma está correta nem redirecione silenciosamente nenhuma ferramenta. Resolva o destino pretendido a partir do contexto explícito da tarefa; se isso não resolver o conflito, pergunte ao usuário. Pause mutações dependentes até que o conflito seja resolvido.

Uma vez estabelecida a região pretendida, verifique se o CLI pode ler os IDs exatos do aplicativo e ambiente MCP, e carregue essa região e esses IDs explicitamente nas mutações subsequentes. O status de login ou um rótulo de região sozinho é insuficiente. Se a verificação falhar, relate a falha sem inferir sua causa e pause mutações dependentes. Continue o trabalho independente cujo destino está estabelecido.

1. Chame webflow_guide_tool antes de qualquer outra ferramenta MCP do Webflow. O guia ao vivo e os esquemas de ação são autoritativos para argumentos e respostas atuais.
2. Use ferramentas MCP do Webflow para operações do Webflow, exceto a transferência explícita para o CLI para valores de variáveis de ambiente. Nunca chame APIs do Webflow diretamente.
3. Inclua o parâmetro context obrigatório em cada chamada de ferramenta. Escreva 15-25 palavras em perspectiva de terceira pessoa.
4. Roteie pela capacidade que a tarefa requer:
   • Use data_apps_tool para criar aplicativos com origem no GitHub; inspecionar aplicativos, ambientes, domínios, registros de implantação, logs e metadados de variáveis; gerenciar origens e ambientes do GitHub; e enfileirar implantações do GitHub.
   • Use data_variable_tool para variáveis de Designer de cor, tamanho, fonte e CSS.
   • Use webflow-cli:cloud para aplicativos com origem CLI/local, builds e implantações locais, ou criar e atualizar valores de variáveis de ambiente.
5. Se data_apps_tool não estiver disponível, relate que a capacidade MCP de Cloud Apps não está habilitada. Não a contorne com uma solicitação de API direta.

Nunca peça ao usuário para colar um valor de variável de ambiente ou segredo no chat. Para uma criação ou atualização, delegue a webflow-cli:cloud e exija um prompt oculto, stdin ou arquivo protegido. Nunca passe um segredo como argumento posicional.

2. Resolva o destino

Descubra identificadores nesta ordem:

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

Os nomes dos aplicativos são únicos apenas dentro de um site, então resolva um aplicativo nomeado com site_id + name. Se vários recursos corresponderem, apresente metadados distintivos e exija que o usuário selecione um antes de qualquer mutação. Use o guia ao vivo para mecanismos de filtro, paginação, cursor e lote de ações.

3. Siga a história de usuário correspondente

Criar um aplicativo com origem no GitHub

1. Estabeleça o nome do aplicativo, URL do repositório GitHub canônico, branch, descrição opcional e se ele é independente ou anexado a um site existente.
2. Para um aplicativo anexado a um site, resolva o ID do site. Omita site_id para independente.
3. Aplique o contrato de montagem antes de visualizar:
   • Um aplicativo independente sempre monta em /; omita mount ou use /.
   • Um aplicativo anexado a um site usa como padrão /app, rejeita / e requer uma montagem válida não raiz ao substituir o padrão.
4. Explique que a criação independente requer um token de usuário com escopo de workspace. O Webflow deriva a instalação do GitHub e valida o acesso ao repositório; não solicite um ID de instalação.
5. Chame create_app com sua execução simulada padrão. Mostre o repositório, branch, anexo, site quando aplicável, montagem e tentativa de implantação inicial.
6. Exija confirm. Imediatamente após a confirmação e antes da execução, registre a hora de início e gere uma idempotency_key estável; execute com dry_run: false, então registre a hora de conclusão. Reutilize essa chave apenas para repetições exatas desta criação.
7. Trate a criação e a implantação inicial como resultados separados. Um aplicativo retornado significa que a criação foi bem-sucedida mesmo que deployStatus seja skipped ou failed. Para triggered, inspecione o ambiente e a implantação; para skipped, verifique o branch ou envie um commit; para failed, preserve o aplicativo e inspecione ou repita a implantação separadamente.
8. Se o aplicativo ou resultado for ilegível, reconcilie antes de repetir:
   • Para um aplicativo anexado a um site, colete candidatos com site_id + name; para um aplicativo independente, colete candidatos por nome.
   • Em ambos os casos, compare o nome, sourceUrl e createdAt de cada candidato com o repositório solicitado e a janela de execução registrada.
   • Continue para ambientes e implantações apenas quando exatamente um candidato corresponder. Não repita enquanto o aplicativo criado permanecer ambíguo.
9. Nunca exclua automaticamente um aplicativo criado porque a implantação falhou. Não trate um link do painel de implantação inicial como a URL pública do ambiente.

Em qual aplicativo e ambiente estou olhando?

1. Use list_apps para encontrar o aplicativo e get_app para seus metadados, incluindo sourceUrl e siteAttached.
2. Use list_environments para relatar o branch, montagem, publicUrl e status da implantação mais recente. Se publicUrl for nulo, relate que nenhum endereço de ambiente voltado para o usuário está disponível; não construa um.
3. Use get_app_domains quando o usuário perguntar onde o aplicativo está acessível.
4. Explique que os resultados de domínio personalizado excluem o nome de host padrão *.webflow.io. Domínios para um aplicativo anexado a um site Webflow regular podem pertencer ao site pai e ser compartilhados por aplicativos irmãos.

O que está implantado e está saudável?

1. Use list_environments para o status da implantação mais recente do ambiente.
2. Use list_deployments, do mais novo para o mais antigo, então get_deployment para a linha do tempo detalhada e metadados de versão da implantação selecionada.
3. Trate starting, building e deploying como estados ativos. Relate qualquer outro status exatamente, em vez de adivinhar seu significado.
4. Uma fase com falha define buildFailedAt ou deployFailedAt enquanto seu timestamp de conclusão correspondente permanece nulo. Um timestamp de conclusão nulo por si só não prova que a fase ainda está em execução.
5. Relate o que é observável: aplicativo e ambiente selecionados, status da implantação, metadados de versão ou commit se retornados, timestamps de fase e lacunas de evidência.

Por que a implantação falhou?

1. Busque a implantação com get_deployment e identifique a fase com falha a partir de seu status e timestamps.
2. Chame get_build_logs apenas quando logsAvailable for verdadeiro. Comece com uma janela since estreita ou filtro q, depois amplie apenas se necessário.
3. Pagine até que nextCursor seja nulo quando um resultado completo for necessário.
4. Trate logsAvailable como um sinal de retenção e recuperação, não como prova de que cada fase produziu entradas de log.
5. Trate um resultado vazio como "nenhum log do lado do servidor recuperável correspondente", não como prova de que o build foi bem-sucedido ou não produziu erros.
6. A saída de build produzida na máquina de um usuário está fora do MCP. Mencione isso apenas quando o usuário disser que a implantação foi construída com o CLI; direcione-os para a saída do CLI de origem para falhas de build local.
7. Relate a fase com falha, timestamps relevantes, a menor evidência útil, a causa inferida e qualquer incerteza. Não apenas reafirme logs brutos.

Por que o aplicativo em execução está falhando?

1. Resolva o ambiente exato e chame get_runtime_logs.
2. Restrinja por since e q antes de recuperar uma janela ampla. Pagine completamente quando a conclusão depender da ausência.
3. Os logs de tempo de execução podem não estar disponíveis devido à retenção. Trate um resultado vazio como nenhum log recuperável e relate a limitação.
4. Correlacione evidências de tempo de execução com o registro de implantação mais recente quando útil, mas não afirme causalidade apenas com base no tempo.
5. Relate o padrão de erro observado, intervalo afetado, causa provável, evidências e limitações.

A configuração necessária está presente?

1. Estabeleça o conjunto de chaves necessário a partir de uma fonte autoritativa: uma lista de chaves fornecida pelo usuário, um esquema de configuração de projeto ou requisito documentado, ou um ambiente de referência que o usuário designe explicitamente como completo.
2. Se a fonte for um arquivo protegido contendo valores, execute extração determinística apenas de chaves localmente e emita apenas nomes de chaves. Nunca abra a fonte através de uma leitura visível pelo modelo ou inclua seus valores no chat ou saída da ferramenta.
3. Obtenha uma designação de sigilo autoritativa para cada chave necessária do usuário, de um esquema de projeto ou requisito documentado, ou de um ambiente de referência explicitamente designado como autoritativo para sigilo. Um arquivo .env ou lista de chaves simples estabelece apenas nomes; nunca infira sigilo a partir de nomes de chaves.
4. Resolva o ambiente, chame list_variables e compare suas chaves e metadados de sigilo com os requisitos estabelecidos. Ele prova o que está configurado, não o que é necessário. Esgote a paginação antes de concluir que uma chave está faltando.
5. Relate chaves e metadados apenas. Entradas secretas têm isSecret: true e nenhum valor; um valor secreto ausente é esperado.
6. Se o conjunto necessário ou qualquer designação de sigilo não estiver resolvido, pare antes de uma mutação do CLI ou implantação dependente, a menos que o usuário estabeleça explicitamente que nenhuma configuração é necessária.
7. Para chaves ausentes ou mal classificadas, encaminhe para webflow-cli:cloud sem solicitar valores no chat. Após a gravação, verifique as chaves necessárias e o sigilo com list_variables. Se falhar parcialmente, relate as chaves com falha sem valores e pare antes da implantação; preserve as chaves bem-sucedidas e o ambiente.

Por que este ambiente está servindo o branch ou rota errada?

1. Resolva o ambiente exato e relate seu branch atual, montagem, publicUrl e status da implantação mais recente. Relate um publicUrl nulo sem construir um endereço.
2. Compare o branch e a montagem atuais com o mapeamento pretendido pelo usuário. Se a solicitação for apenas diagnóstica, pare após relatar a incompatibilidade.
3. Se a correção alterar a montagem, chame get_app e use siteAttached: / é válido apenas quando falso; um aplicativo anexado a um site requer uma montagem não raiz. Não infira anexo a partir de siteId.
4. Para uma correção, mostre o mapeamento exato antes e depois. Explique que update_environment é imediato, não tem execução simulada e não implanta código.
5. Exija confirm, chame update_environment uma vez e relate o ambiente retornado, publicUrl e mountRefreshStatus.
6. Para um resultado ilegível ou incerto, localize o env_id original. Se usar o novo branch esperado como filtro, aceite um ambiente retornado apenas quando seu ID for igual ao env_id original, então compare seu branch e montagem com os valores solicitados. Um ID diferente ou nenhum destino original correspondido exclusivamente é ambíguo: não continue ou repita. Nunca reutilize o filtro de branch antigo após uma atualização que altere o branch.
7. Uma atualização de montagem com falha ou desconhecida não significa que a atualização do ambiente foi revertida. Relate o roteamento como incerto e não repita apenas porque a atualização falhou.
8. Se o branch mudou e o usuário deseja que seu código seja implantado, trate trigger_deployment como uma mutação separada visualizada e confirmada.

Criar um ambiente isolado para um branch e implantá-lo

1. Resolva o aplicativo existente, chame get_app e valide a montagem proposta com siteAttached antes de visualizar a mutação.
2. Pagine através de list_environments para verificar se o branch ou montagem solicitado já está em uso.
3. Mostre o branch e montagem propostos. Explique que create_environment é imediato, não tem execução simulada e cria um mapeamento sem implantar código.
4. Gere uma idempotency_key estável, exija confirm e chame create_environment. Reutilize essa chave apenas para repetições exatas.
5. Relate o ambiente retornado, publicUrl e mountRefreshStatus. Se o resultado for incerto, procure o branch esperado e compare o ID do ambiente, branch e montagem; use um ID retornado para distinguir criações concorrentes. Não repita enquanto o ambiente criado permanecer ambíguo.
6. Uma atualização com falha significa que a criação foi bem-sucedida, mas o roteamento pode estar incompleto. Não repita a criação ou exclua o ambiente automaticamente.
7. Antes de implantar este novo ambiente, siga "A configuração necessária está presente?" como uma porta de entrada obrigatória. Continue apenas após os requisitos e sigilo serem verificados, ou o usuário estabelecer explicitamente que nenhum é necessário. Em seguida, use o fluxo de trabalho de implantação abaixo para visualização, confirmação, atribuição e monitoramento.

Esta implantação pode ser repetida, revertida ou reconstruída a partir do HEAD do branch?

Use a execução simulada padrão da mutação como a verificação de capacidade. Não infira elegibilidade a partir de logs ausentes, metadados do aplicativo ou metadados de implantação.

Para uma nova implantação a partir do branch conectado ou de um commit anterior exato:

1. Resolva o ambiente. Para uma repetição ou reversão, resolva também a implantação anterior exata.
2. Realize a descoberta de configuração apenas quando o usuário a solicitar, as evidências de implantação indicarem variáveis ausentes ou mal classificadas, o commit selecionado tiver requisitos de configuração documentados ou o servidor rejeitar a implantação por motivos de configuração. Caso contrário, prossiga sem inspeção de configuração.
3. Para uma reversão, explique que ela reimplantará o commit da implantação de destino, não a implantação em si; use trigger_deployment com o deployment_id de destino.
4. Exija confirm e execute uma vez. Se a chamada for de uma mutação com falha, use o mesmo idempotency_key da chamada com falha.
5. Relate o status do acionamento. Uma resposta de acionamento não prova que a implantação foi concluída. Uma implantação acionada é verificável com get_deployment, list_deployments e get_build_logs apenas quando a implantação posterior aparecer nos registros.
6. Se o resultado da mutação for ilegível, liste as implantações mais recentes. Se uma nova implantação não aparecer nos registros, relate que o acionamento foi recebido, mas o resultado não pode ser verificado.

Relatar implantações entre IDs de implantação

Para relatar status de múltiplas implantações, use get_deployment para cada deployment_id. Se outputs simultâneos forem necessários, use uma chamada de ferramenta com múltiplas ferramentas por vez.

4. Manipule respostas incomuns

• Resposta não analisável: Se uma ferramenta MCP do Webflow retornar uma resposta inesperada, informe o usuário e sugira verificar a documentação mais recente.
• Erro de recurso não encontrado: Verifique duplicatas (por exemplo, com site_id + name para aplicativos anexados a sites, ou por nome para aplicativos independentes). Se encontrado, use o registro existente; caso contrário, informe o usuário e pause.
• Erro de taxa limitada: Recue, espere e repita a chamada uma vez. Se falhar novamente, informe o usuário.
• Campos faltantes: Se uma resposta da ferramenta omitir um campo esperado, lide com ausência parcial; não invente dados.
• Incompatibilidade de permissão: Relate o erro exato. Não ignore permissões insuficientes ou tente contornar.
• Resultados vazios: Retorne "Nenhum resultado encontrado" sem explicação adicional.

Restrições

• Pare se o conjunto necessário de variáveis de ambiente ou designações de sigilo não puder ser resolvido.
• Pare se o fluxo de implantação falhar.
• Não infira informações sobre variáveis de ambiente de seus nomes.
• Não construa URLs públicas artificialmente dos IDs do aplicativo e ambiente.
• Se a(s) ferramenta(s) MCP do Webflow necessária(s) não estiver habilitada(s), informe o usuário imediatamente.
• Se um aplicativo ou ambiente criado não puder ser lido, pare; não repita cegamente.