Automação do GitHub via Rube MCP

Use o kit de ferramentas do GitHub da Composio através do Rube MCP, preservando a política do repositório, a identidade exata da revisão e a proteção de branches.

Quando Usar

Use para tarefas programáticas de issues, pull requests, branches, Actions, deployments, colaboradores ou proteção do GitHub quando o Rube MCP estiver disponível. Prefira o fluxo de trabalho nativo gh ou um comando de mantenedor específico do repositório quando a política local do repositório exigir.

Configuração

1. Confirme se RUBE_SEARCH_TOOLS está disponível.
2. Pesquise os esquemas atuais da ferramenta do GitHub antes de compor chamadas.
3. Use RUBE_MANAGE_CONNECTIONS com o kit de ferramentas github e complete o OAuth somente se a conexão não estiver ativa.
4. Resolva o owner/repo exato; não confie em um repositório com nome semelhante.

Nunca solicite, imprima ou persista credenciais do GitHub em prompts ou artefatos.

Portão de Política do Repositório

Antes da mutação, leia AGENTS.md, a documentação de contribuição e de mantenedor, e inspecione o branch padrão e a proteção efetiva. Comandos nativos do repositório e verificações obrigatórias têm precedência sobre operações genéricas do Rube.

Se um repositório fornecer um comando de merge ou release protegido, use-o em vez da ferramenta de merge genérica. Em agentic-awesome-skills, use antigravity-maintainer-batch-release e npm run merge:batch para que a revisão exata do SHA, a vinculação de suítes de verificação recentes e o main protegido sejam aplicados.

Fluxos de Trabalho

Issues

1. Liste ou pesquise issues existentes antes de criar uma duplicata.
2. Distinga issues de pull requests em resultados mistos.
3. Leia o item atual, comentários, rótulos e PRs vinculados antes de alterar o estado.
4. Crie, comente, rotule, atribua ou feche apenas dentro do escopo solicitado pelo usuário.
5. Releia o item e verifique o estado resultante.

Paginação até que o conjunto de resultados solicitado esteja completo. Trate a omissão silenciosa de rótulos ou atribuídos como uma falha de permissão, não como sucesso.

Pull Requests

1. Resolva o PR e capture seu número, base, SHA completo do head, estado de rascunho, autor, identidade do fork e capacidade de merge.
2. Inspecione arquivos alterados, revisões, conversas e execuções de verificação obrigatórias.
3. Vincule cada decisão de revisão ou aprovação ao SHA completo do head atual.
4. Crie ou atualize o corpo do PR de forma verídica; nunca marque testes pendentes ou revisões como concluídas.
5. Imediatamente antes do merge, releia a identidade da base/head, a proteção do branch, a capacidade de merge, as verificações obrigatórias e a política do repositório.
6. Use o caminho de merge protegido do repositório. Chame uma ferramenta de merge genérica apenas quando a política permitir e o usuário autorizar o merge.
7. Verifique se o PR relata MERGED e confirme se o branch de destino contém o commit pretendido.

Não trate uma chamada de API bem-sucedida que habilita o auto-merge ou enfileira trabalho como um merge imediato.

Branches e Referências

1. Resolva o SHA do commit de origem e a ref de destino explicitamente.
2. Crie branches de tópico em vez de atualizar branches protegidos/padrão diretamente.
3. Rejeite atualizações não-fast-forward ou forçadas, a menos que o usuário as autorize explicitamente e a política do repositório as permita.
4. Confirme a ref remota após a mutação.

Exclusão, force-push, alterações no branch padrão e alterações de proteção são ações destrutivas ou de alto impacto que exigem autorização explícita.

Actions e Deployments

1. Resolva o workflow por ID ou caminho confiável e confirme o suporte a workflow_dispatch antes do dispatch.
2. Vincule a inspeção da execução ao evento, ref e SHA do head pretendidos.
3. Distinga os estados de queued, in_progress, action_required, completed e skipped.
4. Leia os logs de jobs com falha antes de propor alterações de origem.
5. Aguarde o sucesso terminal e verifique a superfície implantada ou publicada separadamente.

Não aprove execuções de workflow de fork por ID de execução bruta quando o repositório fornecer um comando de aprovação protegido.

Permissões e Proteção

1. Leia colaboradores, função, proteção de branch e regras aplicáveis antes de propor alterações.
2. Trate uma resposta de proteção 404 como "não configurada" apenas após confirmar a identidade do repositório e do branch.
3. Mostre a política exata antes/depois e o impacto antes de qualquer mutação de proteção ou permissão.
4. Releia o estado efetivo após a alteração.

Regras de Falha

• Resolva novamente os esquemas da ferramenta quando o Rube relatar parâmetros ausentes ou alterados.
• Pare em ambiguidade de repositório, SHA de head/base desatualizado, permissões ausentes, paginação incompleta ou estado de proteção inconclusivo.
• Nunca ignore verificações obrigatórias, revisões, filas de merge, comandos de mantenedor ou proteção de branch do lado do servidor.

…