vibecoder

# VibeCoder **Crie issues no GitHub pelo celular, receba PRs (Pull Requests) automaticamente, revise e solicite correções com um joinha.** O VibeCoder é um worker automatizado de issues do GitHub movido por uma CLI de agente de codificação. Ele monitora seus repositórios, pega issues, escreve código, executa verificações de qualidade e abre pull requests — tudo sem você tocar no teclado. Ele é **agnóstico em relação ao provedor**: `claude` ([Claude Code](https://docs.anthropic.com/en/docs/claude-code)) é o padrão, e `codex` (a CLI do OpenAI Codex), `gemini` (a CLI do Gemini) e `deepseek` (DeepSeek, servido através da CLI do Claude Code) são integrados e escolhidos por configuração. ## Como Funciona 1. Você cria uma issue no GitHub (por exemplo, pelo celular). 2. O VibeCoder Worker detecta e se auto-atribui a issue. 3. O worker cria um branch de feature e delega o trabalho ao Coding Agent configurado. 4. O agente escreve as alterações de código. 5. O worker executa verificações de qualidade (linting, testes, formatação). 6. Se as verificações passarem, o worker abre um Pull Request no GitHub. 7. Você revisa o PR, deixa comentários ou dá um joinha para acionar correções. 8. O worker aplica o feedback e envia atualizações. 9. Você aprova e faz o merge do PR. ## Escolha seu agente de codificação O agente de codificação é uma camada separável. Quatro provedores são integrados: | Provider id | Agent | Credential file | | --- | --- | --- | | `claude` (default) | Claude Code | `claude/provider.env` | | `codex` | Codex CLI | `codex/provider.env` | | `gemini` | Gemini CLI | `gemini/provider.env` | | `deepseek` | DeepSeek (via Claude Code CLI) | `deepseek/provider.env` | Selecione um com a chave `agent_provider` em `.config.json`. Hosts mistos podem optar por seleção com reconhecimento de cota. ## Principais Recursos - **Pipeline de issue para PR**: Escreva uma issue, receba um PR. O worker cuida de branching, codificação, testes e criação do PR. - **Ciclo de feedback de revisão**: Deixe comentários no PR, dê joinha para acionar correções. - **Clarificação e refinamento**: Se a issue estiver pouco clara, o worker faz perguntas antes de começar. - **Modo de planejamento**: Adicione a label `planning` para obter divisões de tarefas e sub-issues em vez de implementação direta. - **Resposta a perguntas**: Adicione a label `question` para obter respostas sobre a base de código sem implementação. - **Correção automática de ortografia**: Verificações de ortografia com falha em PRs são corrigidas automaticamente. - **Correção automática de falhas de CI**: Verificações de CI com falha em PRs abertos são diagnosticadas e corrigidas automaticamente. - **Framework de tarefas ociosas**: Quando não existe trabalho reivindicável, o worker registra tarefas ociosas de baixa prioridade (segurança, boas práticas, etc.). - **Varreduras de segurança**: Execuções ociosas realizam varreduras de segurança nos repositórios monitorados. - **Fila de trabalho baseada em prioridade**: Prioriza feedback de PR, depois correções de ortografia, remediação de CI, etc. - **Otimização de custos**: Seleção de modelo por fase, cache de prompt e rastreamento de uso de tokens. - **Callbacks pós-execução**: Executáveis opcionais executados após execuções bem-sucedidas/malsucedidas. - **Configuração por repositório**: Personalize o comportamento do worker por repositório. - **Melhorias de milestone**: Notificações de progresso, roll-back automático de branches travados. - **Autocorreção**: Execução em cópia sombra, resets automáticos de repositório, limpeza de disco, resiliência a falhas. - **Seguro por padrão**: Processa apenas issues de autores permitidos com labels configuradas. - **Extensível**: Adicione novas funcionalidades via comandos Deno/TypeScript. ## Qualidade e controle Nada vai para o branch padrão (prod) sem a sua revisão. Toda alteração chega como um PR; você revisa, solicita correções e aprova antes do merge. O worker segue TDD, KISS, DRY e executa todos os portões de qualidade (`deno test`, `deno lint`, `deno check`, `deno fmt --check` e semgrep). ## Início Rápido ### macOS / Linux ```bash # Clone o repositório gh repo clone <your-org>/VibeCoder cd VibeCoder # Configure via variáveis de ambiente VIBE_ALLOWED_AUTHOR=myusername \ VIBE_REPOS="myorg/repo1,myorg/repo2" \ ./setup.sh # Inicie o worker ./run.sh ``` ### Windows (PowerShell) ```powershell # Clone o repositório gh repo clone <your-org>/VibeCoder cd VibeCoder # Configure $env:VIBE_ALLOWED_AUTHOR = "myusername" $env:VIBE_REPOS = "myorg/repo1,myorg/repo2" .\setup.ps1 # Inicie o worker .\run.ps1 ``` ## Arquitetura O worker usa uma arquitetura de launcher fino + Deno TypeScript. Os pontos de entrada são scripts shell/PowerShell mínimos que delegam ao Deno toda a lógica de negócio. Multiplataforma: macOS, Linux e Windows. O worker roda dentro de um contêiner de privilégio mínimo. O confinamento é obrigatório. O GitHub é o único plano de controle remoto normal. ## Requisitos - Um runtime de contêiner suportado: Apple `container` no macOS, Docker ou Podman no Linux e Windows. - [Deno](https://deno.com/) 2+ — a única ferramenta de host do launcher. - `bash` (macOS/Linux) ou PowerShell (Windows) para executar o launcher. - Apenas para configuração: Git e uma GitHub CLI autenticada. ## Documentação - [Overview](docs/OVERVIEW.md): Passo a passo em página única. - [Label Flows](docs/workflows/label-flows.md): Qual label quando. - [Usage Guide](docs/USAGE.md): Criando issues, fluxo de PR. - [Workflows Overview](docs/workflows/README.md): Manual do usuário para donos de repositório. - [Quorum](docs/QUORUM.md): Executando vários provedores ao mesmo tempo.