← Voltar ao curso
Nível 3 — Automação e escala · Módulo 3.5 — Automação: routines, headless e CI

3.5.5 · GitHub Actions

5 min de vídeo TEC BASIS

Objetivo: ao final, o consultor monta um workflow que responde a @claude num PR e outro que roda por cron, e sabe passar as skills do plugin da Wayon para dentro do CI.

O que você precisa levar desta aula

  1. anthropics/claude-code-action@v1, instalada com /install-github-app (exige admin do repositório). O modo é detectado: sem prompt responde a @claude; com prompt executa direto.
  2. Todo ajuste fino vai em claude_args, que aceita qualquer argumento do CLI — --max-turns (padrão 10), --model e --allowedTools são os três que mais importam num pipeline.
  3. O prompt aceita invocação de skill, e a action instala plugin antes de executar (plugin_marketplaces + plugins) — então a skill que a squad empacotou no plugin da Wayon roda dentro do CI.

Os inputs da action

Input Para que serve Obrigatório
anthropic_api_key Chave da API, sempre via secret Sim, para API direta (não para Bedrock/Vertex)
prompt Instrução, em texto ou invocação de skill Não — sem ele, responde à menção
claude_args Qualquer argumento do CLI do Claude Code Não
plugin_marketplaces Lista de URLs Git de marketplace de plugin, uma por linha Não
plugins Lista de plugins a instalar antes de executar, uma por linha Não
github_token Token para a API do GitHub Não
trigger_phrase Frase de gatilho (padrão: @claude) Não
use_bedrock / use_vertex Usar Amazon Bedrock ou Google Cloud em vez da API direta Não

Workflow 1 — responder a @claude num PR ou issue

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Sem prompt, a action responde a menções de @claude em comentário. O comentário precisa dizer @claude, não /claude — é a causa nº 1 de "não respondeu".

Workflow 2 — rollup diário por cron

name: Rollup Meridiano
on:
  schedule:
    - cron: "0 9 * * *"
  workflow_dispatch:
jobs:
  rollup:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Resuma os commits de ontem e as issues abertas dos objetos CAP do Meridiano"
          claude_args: |
            --max-turns 10
            --allowedTools Read,Grep,Glob

Duas escolhas deliberadas: workflow_dispatch junto do cron, para disparar à mão ao testar; e --allowedTools só de leitura, porque um workflow que relata não precisa de ferramenta de escrita.

Workflow 3 — rodando a skill do plugin da Wayon no CI

name: Revisão de spec
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  revisao:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/wayon/claude-plugins.git"
          plugins: "wayon-sap@wayon-plugins"
          prompt: "/wayon-sap:revisao-spec"

É o fechamento do arco do nível: a skill do módulo 2.4, empacotada em plugin no módulo 3.3, rodando desassistida no módulo 3.5. Para skill que vive no próprio repositório (em .claude/skills/), rode actions/checkout antes do passo da action e passe /nome-da-skill.

Migrando da versão beta

Quem tem workflow da beta precisa ajustar — a v1 tem mudança incompatível:

Input da beta Equivalente na v1
@beta @v1
mode: "tag" / mode: "agent" (removido — detectado automaticamente)
direct_prompt prompt
custom_instructions claude_args: --append-system-prompt
max_turns claude_args: --max-turns
model claude_args: --model
allowed_tools claude_args: --allowedTools

Actions ou Code Review gerenciado?

Situação Escolha
Revisão automática em todo PR, sem manter workflow Code Review gerenciado (aula 3.5.4)
Fluxo próprio: responder a menção, implementar spec, gerar relatório GitHub Actions (esta aula)
Rodar a skill da squad dentro do CI GitHub Actions, com plugins

Os dois convivem no mesmo repositório e não competem.

Regra Wayon Em repositório de cliente, todo workflow do Claude Code começa com --allowedTools mínimo e --max-turns explícito. Workflow que só relata roda com ferramenta de leitura apenas. Nenhum workflow recebe permissão de escrita em branch protegido, e a chave da API vive exclusivamente em secret do repositório — nunca no arquivo do workflow, que é versionado e visível para todo mundo com acesso ao repo.

📖 GitHub Actions · Repositório da action

Quiz — 5 questões

1.Você monta um workflow com a action da v1 e passa um prompt. Alguém comenta @claude revisa isso aqui num PR e nada acontece com aquele workflow.
  • a)É bug da v1 — prompt e resposta a menção deveriam funcionar juntos

    Não é bug: o modo é detectado a partir da presença do prompt, e isso é comportamento documentado.

  • b)Com prompt preenchido, a action roda em modo automação e executa aquele prompt direto, em vez de esperar menção

    Correto. Para responder a menção, o workflow não deve passar prompt.

  • c)Falta declarar mode: "tag" no workflow

    mode foi removido na v1 — era input da versão beta, e hoje o modo é detectado automaticamente.

Ver resposta e por quê
❌a) Não é bug: o modo é detectado a partir da presença do prompt, e isso é comportamento documentado.
✅b) Correto. Para responder a menção, o workflow não deve passar prompt.
❌c) mode foi removido na v1 — era input da versão beta, e hoje o modo é detectado automaticamente.
2.Um workflow por cron gera o rollup diário de pendências do Meridiano — só lê e escreve um resumo. Qual configuração é a mais adequada?
  • a)--allowedTools só com ferramentas de leitura, mais --max-turns explícito

    Correto. Workflow que relata não precisa de ferramenta de escrita, e o teto de turnos evita loop virar fatura.

  • b)Deixar as ferramentas no padrão, já que o workflow é simples

    O padrão é mais permissivo do que a tarefa exige — dar o mínimo é a regra Wayon para repositório de cliente.

  • c)--max-turns 1, para garantir custo mínimo

    Um único turno provavelmente não completa a tarefa; o objetivo é ter teto, não impedir o trabalho.

Ver resposta e por quê
✅a) Correto. Workflow que relata não precisa de ferramenta de escrita, e o teto de turnos evita loop virar fatura.
❌b) O padrão é mais permissivo do que a tarefa exige — dar o mínimo é a regra Wayon para repositório de cliente.
❌c) Um único turno provavelmente não completa a tarefa; o objetivo é ter teto, não impedir o trabalho.
3.A squad empacotou a skill de revisão de spec no plugin wayon-sap, publicado no marketplace da Wayon. Como rodar essa skill dentro do CI?
  • a)Não é possível — plugin é instalação local, o CI não alcança

    A action instala plugin antes de executar, justamente para esse caso.

  • b)Copiar o conteúdo da skill para dentro do prompt, como texto

    Funciona mal e duplica: a skill passa a existir em dois lugares e sai de sincronia com o plugin.

  • c)Passar plugin_marketplaces e plugins na action, e usar prompt com a skill namespaced (/wayon-sap:revisao-spec)

    Correto. O prompt aceita invocação de skill, e o plugin é instalado antes da execução.

Ver resposta e por quê
❌a) A action instala plugin antes de executar, justamente para esse caso.
❌b) Funciona mal e duplica: a skill passa a existir em dois lugares e sai de sincronia com o plugin.
✅c) Correto. O prompt aceita invocação de skill, e o plugin é instalado antes da execução.
4.Você quer instalar a integração, mas não tem papel de admin no repositório do cliente.
  • a)Dá para instalar sem admin; só a criação de secret exige o papel

    Tanto a instalação do GitHub App quanto a criação de secret exigem admin do repositório.

  • b)Basta rodar /install-github-app com a flag de usuário comum

    Não existe essa flag: o requisito de admin é do GitHub, não do Claude Code.

  • c)Não dá — instalar o app e criar secret exigem admin; é preciso acionar quem tem o papel

    Correto, e vale resolver antes de prometer a automação no plano de projeto.

Ver resposta e por quê
❌a) Tanto a instalação do GitHub App quanto a criação de secret exigem admin do repositório.
❌b) Não existe essa flag: o requisito de admin é do GitHub, não do Claude Code.
✅c) Correto, e vale resolver antes de prometer a automação no plano de projeto.
5.Uma squad quer revisão automática em todo PR, sem manter workflow nenhum no repositório. Qual é a escolha certa?
  • a)GitHub Actions com on: pull_request, que é o caminho padrão para revisão

    Funciona, mas exige manter um workflow — e o enunciado pede explicitamente não manter.

  • b)Code Review gerenciado (aula 3.5.4), que roda na infraestrutura da Anthropic sem workflow no repositório

    Correto — lembrando que é preview, só Team e Enterprise, e indisponível sob Zero Data Retention.

  • c)Uma routine com gatilho de GitHub (aula 3.5.1)

    Routine reage a PR, mas é feita para executar uma tarefa que você descreveu, não para o fluxo de revisão com achados inline por severidade.

Ver resposta e por quê
❌a) Funciona, mas exige manter um workflow — e o enunciado pede explicitamente não manter.
✅b) Correto — lembrando que é preview, só Team e Enterprise, e indisponível sob Zero Data Retention.
❌c) Routine reage a PR, mas é feita para executar uma tarefa que você descreveu, não para o fluxo de revisão com achados inline por severidade.

Quiz — 5 questões

1.Um PR de objetos CAP do Meridiano recebeu três achados 🔴 Important do Code Review. O que acontece com o merge?
  • a)O PR fica bloqueado até os três serem corrigidos

    O check run sempre termina com conclusão neutra, justamente para não bloquear merge por branch protection.

  • b)O PR é aprovado automaticamente se ninguém contestar os achados em 24h

    O Code Review nunca aprova PR — aprovação continua sendo ato de uma pessoa.

  • c)Nada — o check run é sempre neutro; o julgamento continua sendo de uma pessoa

    Correto. É desenho deliberado, para não atropelar o processo de revisão que já existe.

Ver resposta e por quê
❌a) O check run sempre termina com conclusão neutra, justamente para não bloquear merge por branch protection.
❌b) O Code Review nunca aprova PR — aprovação continua sendo ato de uma pessoa.
✅c) Correto. É desenho deliberado, para não atropelar o processo de revisão que já existe.
2.O Code Review está reclamando de formatação em arquivos gerados, e isso está poluindo as revisões da squad. Qual é o caminho certo?
  • a)Criar um REVIEW.md na raiz, listando o que não deve ser reportado

    Correto. REVIEW.md é injetado como instrução de prioridade máxima em cada agente da revisão.

  • b)Acrescentar a exceção ao CLAUDE.md do projeto

    Funciona parcialmente: o Code Review lê o CLAUDE.md como contexto, mas instrução específica de revisão pega com muito mais força no REVIEW.md.

  • c)Desabilitar o Code Review naquele repositório

    Joga fora todo o valor por um problema de calibração que tem solução direta.

Ver resposta e por quê
✅a) Correto. REVIEW.md é injetado como instrução de prioridade máxima em cada agente da revisão.
❌b) Funciona parcialmente: o Code Review lê o CLAUDE.md como contexto, mas instrução específica de revisão pega com muito mais força no REVIEW.md.
❌c) Joga fora todo o valor por um problema de calibração que tem solução direta.
3.Qual é a diferença entre um achado 🟡 Nit e um 🟣 Pre-existing?
  • a)Nit é de estilo e Pre-existing é de segurança

    A distinção não é por classe de problema; é por origem e gravidade.

  • b)Nit foi verificado e Pre-existing é só suspeita não confirmada

    Os dois passam pela mesma etapa de verificação; a diferença é outra.

  • c)Nit é um problema menor introduzido pelo PR; Pre-existing é um bug que já existia na base e não foi introduzido por ele

    Correto — e o roxo é útil em rollout, porque cataloga dívida que ninguém tinha mapeado.

Ver resposta e por quê
❌a) A distinção não é por classe de problema; é por origem e gravidade.
❌b) Os dois passam pela mesma etapa de verificação; a diferença é outra.
✅c) Correto — e o roxo é útil em rollout, porque cataloga dívida que ninguém tinha mapeado.
4.A Wayon está negociando um projeto em que o cliente exige Zero Data Retention. Pode prometer Code Review gerenciado na proposta?
  • a)Não — o recurso é indisponível para organização com Zero Data Retention habilitado

    Correto. Prometer em proposta seria erro; o /code-review local continua disponível como alternativa.

  • b)Sim, desde que o repositório do cliente seja privado

    A restrição é do Zero Data Retention na organização, não da visibilidade do repositório.

  • c)Sim, mas só no comportamento Manual

    O comportamento de disparo não muda a indisponibilidade sob Zero Data Retention.

Ver resposta e por quê
✅a) Correto. Prometer em proposta seria erro; o /code-review local continua disponível como alternativa.
❌b) A restrição é do Zero Data Retention na organização, não da visibilidade do repositório.
❌c) O comportamento de disparo não muda a indisponibilidade sob Zero Data Retention.
5.O check run diz que a revisão encontrou problemas, mas você não vê nenhum comentário inline no diff. O que fazer? ---
  • a)Comentar @claude review para rodar de novo, porque a revisão falhou

    A revisão não falhou — os achados existem, só não estão onde você procurou.

  • b)Procurar nos outros dois lugares: a tabela em Check run → Details e as anotações na aba Files changed

    Correto. Se houve push durante a revisão, achados de linha que mudou vão para "Additional findings" no corpo, não para inline.

  • c)Clicar em Re-run na aba Checks do GitHub

    O botão Re-run do GitHub não redispara o Code Review — e, de todo modo, o problema aqui não é a revisão não ter rodado.

Ver resposta e por quê
❌a) A revisão não falhou — os achados existem, só não estão onde você procurou.
✅b) Correto. Se houve push durante a revisão, achados de linha que mudou vão para "Additional findings" no corpo, não para inline.
❌c) O botão Re-run do GitHub não redispara o Code Review — e, de todo modo, o problema aqui não é a revisão não ter rodado.