Lançamento Unificado de Plugins de Navegador

Você é responsável por criar o plugin e gerenciar sua entrega. O usuário é responsável por expressar suas necessidades, fornecer feedback sobre a experiência e realizar operações manuais necessárias. Por padrão, o usuário passará pelas seguintes etapas: Expressar ideia → Testar primeira versão → Indicar o que precisa ser alterado → Confirmar cronograma de lançamento específico → Obter link de instalação.

Quando Usar

• Use quando um usuário quiser transformar uma ideia em linguagem natural em uma extensão de navegador.
• Use ao continuar, depurar, empacotar, enviar ou lançar uma extensão existente.
• Não use para desenvolvimento de sites comuns ou perguntas sobre conhecimento de extensões de navegador que não exigem implementação.

Esta habilidade é uma skill compartilhada, independente do host, responsável por orquestrar sub-skills, ferramentas de navegador controladas e ferramentas auxiliares locais. No início, identifique o host atual e valide as capacidades de arquivos, terminal, navegador e sub-skills de acordo com as Instruções de Compatibilidade do Agente; o sucesso da instalação não significa que a ferramenta está pronta para uso. O primeiro lançamento de adaptação tem como base o Chrome / Manifest V3. Quando nenhum navegador for especificado, o Chrome será considerado uma sugestão modificável e o trabalho continuará de forma independente; se o usuário especificar outro navegador, siga a escolha, verifique as regras da plataforma e não afirme que o verificador do Chrome deste pacote as cobre.

Acordos de Execução

• Novos projetos são, por padrão, tarefas locais formais, sem exigência de GitHub, servidor, domínio pago ou protótipo independente. Projetos existentes devem primeiro ler seus acordos, mantendo o sistema de tarefas existente e o design confirmado.
• Selecione proativamente soluções técnicas reversíveis, verifique o ambiente, crie tarefas, produza, depure e valide. Respostas e autorizações existentes serão mantidas, sem solicitar aprovação gradual do usuário para ações rotineiras.
• Verifique fatos por conta própria; pergunte apenas sobre itens desconhecidos importantes que alterem o propósito, o destino dos dados, os custos ou os compromissos de distribuição. Explique o impacto em cenários do dia a dia e processe apenas os problemas necessários no momento, em uma rodada; continue o trabalho que não depende de respostas enquanto espera. Escolhas importantes não serão confirmadas por silêncio.
• Diga ao usuário "o conteúdo permanece neste computador", "pacote de instalação", "quais operações foram verificadas". Ordens de serviço, Manifest, E2E, ferramentas de build, etc., permanecem em segundo plano; os nomes dos botões da plataforma podem ser referenciados com precisão.
• Escrever código, capturas de tela, verificações estáticas, aceitação, upload, revisão e lançamento têm evidências independentes. Verificações não executadas serão marcadas como "não verificadas" e não serão aprovadas com base na ausência de ferramentas, capturas de tela antigas ou porque o usuário não relatou erros.
• A aceitação real é o limiar de entrega. A primeira versão utilizável, cada ticket de implementação e o pacote candidato final para lançamento devem usar ferramentas de navegador controladas no host atual que foram verificadas como capazes de carregar a extensão e operar os pontos de entrada nativos, completando as operações principais de ponta a ponta e a verificação aplicável de fechamento e reabertura, salvando evidências e passando pelo portão de aceitação, para serem consideradas utilizáveis, entrega concluída ou tarefa fechada. O Playwright MCP é a implementação de referência preferencial; a simulação da API do Chrome, verificações estáticas e a abertura separada de HTML de pop-up não podem substituí-lo. Adaptações específicas e evidências podem ser encontradas em Instruções de Compatibilidade do Agente e Aceitação Independente.
• Quando o host atual não possui um canal de navegador utilizável ou não consegue completar os pontos de entrada reais, forneça o motivo específico de acordo com Preparação de Dependências, pergunte ao usuário se ele deseja instalar/habilitar ou escolher uma solução alternativa controlada recomendada, aguarde a escolha; a aceitação permanecerá blocked, sem alterar silenciosamente para um navegador comum ou pular este nó. Escolhas claras existentes serão mantidas, sem solicitar novamente item por item. A verificação real ainda é necessária após a assistência manual. Somente quando o usuário explicitamente desejar apenas o código-fonte ou solicitar a interrupção, o código-fonte poderá ser entregue dentro desse escopo e marcado como não aceito.
• Salve o estado quando faltarem permissões, aguardando operação manual do usuário ou revisão da loja, explique o próximo passo; suspenda o trabalho que depende dessa condição. Sem capacidade de rastreamento contínuo real, não prometemos monitoramento em segundo plano.

Limitações

• Esta habilidade fornece o fluxo de entrega, o contrato de verificação e as regras de adaptação do host, mas não inclui scripts executáveis, binários de navegador, contas de loja ou credenciais de lançamento.
• Chrome / Manifest V3 é a linha de base padrão; outros navegadores, políticas de distribuição corporativa, taxas de loja e regras de revisão devem ser verificados separadamente com base nas informações oficiais atuais durante a execução.
• Verificações estáticas, impressões digitais de arquivos e relatórios automatizados não provam operações reais do navegador, aprovação da revisão da loja ou instalação online; esses estados devem reter suas evidências diretas.
• Quando o login na conta, pagamento, declaração de identidade, autorização de permissão ou envio final forem necessários, o usuário deve decidir e concluir as operações correspondentes.

Ciclo de Fechamento do Uso do Produto

Ao criar ou alterar fluxos de usuário, é obrigatório executar product-designer, primeiro escrevendo a entrada, ações principais, tratamento de resultados, uso contínuo, saída e recuperação nas especificações existentes de acordo com o Ciclo de Fechamento do Uso do Produto. Operações básicas serão preenchidas proativamente pela IA, e o usuário só será consultado quando houver informações insuficientes sobre escolhas importantes de experiência. A aceitação real final deve incluir repeat_use em duas rodadas consecutivas de uso, com a revisão da experiência do produto e os resultados técnicos registrados separadamente; a entrega não pode ocorrer devido à aprovação de casos de uso técnicos sem o ciclo de fechamento básico.

Eficiência e Encerramento

Ao planejar, revisar final ou refazer, leia Entrega Eficiente: primeiro verifique o ambiente de desenvolvimento e as capacidades especiais do navegador, liste os ACs e as especificações rígidas com antecedência; divida os tickets por risco e revise novamente por impacto da alteração. Evidências reais e revisões biaxiais para o mesmo candidato podem cobrir vários tickets prontos, mas a aceitação final entre módulos ainda deve ser executada. Documentação e arquivamento não repetem testes de produto quando o pacote em execução não é alterado; o encerramento único ocorrerá após a conclusão da aceitação, revisão e documentação de entrega dentro do escopo. Quando o usuário solicitar um CLI independente ou uma sessão completa, mantenha as entradas reais, respostas e registros originais de acordo com esta referência.

Nós Obrigatórios a Serem Executados

"Executar skill" especifica e lê seus pontos de entrada reais e recursos necessários, produz os resultados correspondentes de acordo com o fluxo, registra a origem, entrada, saída e validação; apenas o nome aparecendo, a existência de arquivos ou a leitura não contam como conclusão. Priorize a execução das sub-skills nomeadas; quando o host não puder instalar ou chamar, use apenas a implementação equivalente definida em Instruções de Compatibilidade do Agente e registre claramente o fallback, sem afirmar que a skill original foi executada. Instalação e divisão técnica devem ser concluídas automaticamente o máximo possível; escolhas alternativas quando as ferramentas do navegador não são suportadas, promessas de produto que não podem ser inferidas e custos de conta reais ainda são decididos pelo usuário. A lista de fontes pode ser encontrada em Preparação de Dependências.

Quando faltarem skills necessárias, elas serão preenchidas e executadas através da Skill CLI ou do instalador do host a partir de fontes verificadas e do objetivo atual do Agente, sem substituir por skills desconhecidas com nomes semelhantes. Apenas fallbacks portáteis explicitamente permitidos pela descrição de compatibilidade podem substituir, e a forma real de execução deve ser registrada. Instalação e divisão técnica devem ser concluídas automaticamente o máximo possível; escolhas alternativas quando as ferramentas do navegador não são suportadas, promessas de produto que não podem ser inferidas e custos de conta reais ainda são decididos pelo usuário. A lista de fontes pode ser encontrada em Preparação de Dependências.

Continuar a Partir do Projeto Atual

1. Determine o diretório do projeto; se .extension-launch/ existir, leia primeiro seu estado, especificações, tarefas e evidências. Se outro sistema de tarefas existir, restaure a partir dele. Não reconstrua ou sobrescreva tarefas com base em memórias de chat.
2. De acordo com Instruções de Compatibilidade do Agente e Preparação de Dependências, detecte as skills necessárias, ferramentas de navegador controladas e software de desenvolvimento, registrando separadamente o status de detecção, leitura e execução; preencha o que estiver faltando, não trate a existência de arquivos como capacidade pronta.
3. O agente principal julgará a complexidade por si só e explicará o motivo. Plugins simples seguirão o registro local mínimo; plugins complexos devem seguir Orquestração de Plugins Complexos, com a IA publicando ordens de serviço de especificação, dividindo tickets e atribuindo módulos independentes. De acordo com Tarefas e Recuperação, estabeleça registros de estado, especificações, decisões, tarefas e evidências, e vincule-os às especificações e ordens de serviço reais. De acordo com o ponto final especificado pelo usuário, registre local (uso próprio primeiro), materials (apenas materiais) ou live (lançamento); o valor padrão não é considerado confirmado pelo usuário. Tarefas de lançamento fora do escopo permanecerão não aplicáveis e não serão listadas como pendências do usuário. Conteúdo rascunhado deve ser preenchido, não requisitos confirmados.
4. Selecione o próximo passo de acordo com a tabela abaixo; ao final de cada fase, o agente principal resumirá o progresso, evidências, problemas não resolvidos e a próxima ação. Não entregue a tabela inteira para iniciantes.

Registro Local e Portão

Use ferramentas de arquivo do host de acordo com Tarefas e Recuperação para estabelecer e manter o estado .extension-launch/, especificações, decisões, tarefas e evidências. De acordo com Aceitação Independente, gere uma impressão digital estável para o build atual, registre evidências de operações reais do navegador e gere um novo relatório de portão. Verificações de estrutura estática, empacotamento e relatórios devem ser escritos fora do diretório de build, sem sobrescrever resultados antigos; a verificação da máquina em si não prova que a operação real ocorreu.

Assistência de Lançamento Acionada por Contexto

…