Kaique Mitsuo Silva Yamamoto
IaDesenvolvimento com ia

Automação com Hooks, Rules e Skills — Gatilhos no Workflow de IA

Como funcionam hooks, rules, skills e triggers no Claude Code e Cursor. Configuração prática, exemplos reais e como automatizar back-pressure no ciclo de desenvolvimento.

Hooks, rules e skills são os três mecanismos de automação do Claude Code. Cada um tem um gatilho diferente, um propósito diferente e um nível de granularidade diferente. Entender como eles funcionam — e quando usar cada um — é o que transforma o Claude Code de "chatbot no terminal" em um agente de engenharia com guardrails.


Visão geral — os 3 mecanismos

MecanismoGatilhoO que fazGranularidade
HooksEvento do ciclo de vida (edit, commit, finish)Executa comandos shellGlobal (todo o projeto)
RulesCaminho do arquivo sendo editadoInjeta instruções no contextoPath-scoped (por diretório)
SkillsComando do usuário ou frase de gatilhoCarrega workflow completoDemand-loaded (sob pedido)
Usuário pede: "implemente o endpoint de billing"


┌─────────────────────────────────────────┐
│ 1. RULES avaliadas                      │
│    → .claude/rules/backend.md carregado │
│       (porque o arquivo é .go)          │
│                                         │
│ 2. IA implementa o código              │
│                                         │
│ 3. HOOK onEdit disparado               │
│    → executa: go fmt ./...             │
│    → executa: go vet ./...             │
│                                         │
│ 4. Usuário diz "commit"                │
│    → SKILL commit/ carregado           │
│    → skill executa: git status         │
│    → skill gera mensagem de commit     │
│                                         │
│ 5. HOOK onCommit disparado             │
│    → executa: go test ./...            │
│    → se falhar: commit bloqueado       │
└─────────────────────────────────────────┘

Hooks — gatilhos de ciclo de vida

Hooks são comandos shell executados automaticamente em momentos específicos do ciclo de vida da sessão. Eles são a camada de back-pressure obrigatória — o agente não consegue pular um hook.

Configuração

// .claude/settings.json
{
  "hooks": {
    "onEdit": "pnpm lint:fix",
    "onCommit": "pnpm vitest run",
    "onFinish": "pnpm build"
  }
}

Gatilhos disponíveis

GatilhoQuando disparaCaso de uso
onEditApós cada edição de arquivoLint, format, typecheck
onSaveQuando arquivo é salvoFormatação automática
onCommitAntes de cada commitTestes, build, security scan
onFinishQuando sessão terminaBuild final, notificação
onErrorQuando comando falhaLog, notificação, rollback

Como funciona na prática

Fluxo de uma edição:

1. IA edita src/api/users.ts


2. HOOK onEdit disparado
   → shell: pnpm lint:fix src/api/users.ts

         ├── SUCESSO → continua

         └── FALHOU → IA recebe o output do erro
                      → IA corrige automaticamente
                      → hook roda de novo
                      → loop até passar

Hooks como guardrails (exemplos reais)

// .claude/settings.json — projeto TypeScript
{
  "hooks": {
    "onEdit": "pnpm lint:fix --no-error-if-unmatched",
    "onCommit": "pnpm vitest run && pnpm build",
    "onFinish": "echo 'Session ended at $(date)' >> .claude/session-log.txt"
  }
}
// .claude/settings.json — projeto Go
{
  "hooks": {
    "onEdit": "cd backend/api && go fmt ./... && go vet ./...",
    "onCommit": "cd backend/api && go test ./...",
    "onFinish": "cd backend/api && go build -o bin/api ."
  }
}
// .claude/settings.json — projeto full-stack
{
  "hooks": {
    "onEdit": "pnpm lint:fix && cd backend/api && go fmt ./...",
    "onCommit": "pnpm vitest run && pnpm build && cd backend/api && go test ./...",
    "onFinish": "pnpm build"
  }
}

Comandos complexos em hooks

Para hooks mais complexos, use um script shell:

#!/bin/bash
# .claude/hooks/pre-commit.sh

echo "🔍 Running pre-commit checks..."

# Lint
pnpm lint:fix
if [ $? -ne 0 ]; then
  echo "❌ Lint failed"
  exit 1
fi

# Tests
pnpm vitest run
if [ $? -ne 0 ]; then
  echo "❌ Tests failed"
  exit 1
fi

# Build
pnpm build
if [ $? -ne 0 ]; then
  echo "❌ Build failed"
  exit 1
fi

echo "✅ All checks passed"
// .claude/settings.json
{
  "hooks": {
    "onCommit": "bash .claude/hooks/pre-commit.sh"
  }
}

Por que hooks são "obrigatórios"

Hooks rodam antes do agente prosseguir. Se um hook onCommit falha (exit code != 0), o commit é bloqueado. Isso significa:

  • O agente não consegue commitar código com lint errado
  • O agente não consegue commitar código com testes falhando
  • O agente não consegue commitar código que não compila

É back-pressure automático e inegociável.


Rules — instruções por caminho

Rules são arquivos Markdown com frontmatter YAML que definem instruções condicionais carregadas apenas quando o arquivo editado corresponde ao padrão de caminho.

Estrutura de arquivos

.claude/
├── rules/
│   ├── global.md              # Sempre carregado
│   ├── backend.md             # Carregado para backend/**
│   ├── frontend.md            # Carregado para src/**
│   ├── tests.md               # Carregado para **/*.test.ts
│   ├── database.md            # Carregado para **/*schema*
│   └── security.md            # Carregado para **/*auth*

Formato de uma rule

---
# .claude/rules/backend.md

# Quando carregar esta rule
paths:
  - "backend/**/*.go"
  - "backend/**/*.mod"
  - "backend/**/*.sum"

# Tags opcionais para organização
tags:
  - go
  - backend
---

## Go Conventions

- Go 1.23, framework Gin
- Sempre rodar `go fmt` antes de commitar
- Usar table-driven tests
- Error handling: sempre wrappar com `fmt.Errorf("context: %w", err)`
- Nunca usar `panic` em código de produção
- Usar `context.Context` como primeiro parâmetro de funções que fazem I/O

## Database
- MongoDB driver v2 (nunca v1)
- Redis para cache-aside pattern
- Transações apenas quando necessário (MongoDB replica set)

## API
- Handlers em `internal/handlers/`
- Repositories em `internal/repository/`
- Models em `internal/models/`
- Nunca lógica de negócio em handlers

Como o gatilho funciona

IA edita: backend/api/internal/handlers/user.go


Claude Code avalia paths de todas as rules:
  .claude/rules/global.md     → paths: (nenhum)     → SEMPRE carrega ✅
  .claude/rules/backend.md    → paths: backend/**/*.go → MATCH ✅
  .claude/rules/frontend.md   → paths: src/**          → não match ❌
  .claude/rules/tests.md      → paths: **/*.test.ts    → não match ❌
  .claude/rules/security.md   → paths: **/*auth*       → não match ❌


Contexto da IA: global.md + backend.md
(2 rules carregadas de 5)

Rules para diferentes stacks

---
# .claude/rules/frontend.md
paths:
  - "src/**/*.tsx"
  - "src/**/*.ts"
  - "src/**/*.css"
  - "src/app/**"
---

## React / Next.js
- Sempre usar <Link> do Next.js para navegação interna
- Componentes em PascalCase, arquivos em kebab-case
- Server Components por default, 'use client' só quando necessário
- Tailwind CSS v4 — não usar classes do v3 depreciadas
- Imagens: sempre usar next/image

## Testes
- Vitest (nunca Jest)
- Testing Library para componentes
- vi.fn() para mocks
---
# .claude/rules/tests.md
paths:
  - "**/*.test.ts"
  - "**/*.test.tsx"
  - "**/*.spec.ts"
  - "tests/**"
---

## Test Conventions
- Sempre usar Vitest: import { describe, it, expect, vi } from 'vitest'
- Nomes descritivos em português: it('retorna 400 sem email')
- Testar comportamento, não implementação
- Usar vi.fn() para mocks
- Nunca testar detalhes internos de componentes
---
# .claude/rules/database.md
paths:
  - "**/*schema*"
  - "**/*migration*"
  - "**/*model*"
---

## Database Rules
- Nunca dropar tabelas/collections sem confirmação
- Migrations sempre reversíveis (up + down)
- Índices devem ser criados em migrations, não manualmente
- Nunca expor _id ou __v em responses da API

Rule global (sempre carregada)

---
# .claude/rules/global.md
# Sem paths = sempre carregado
---

## Global Rules
- 2 espaços de indentação
- Aspas simples em TypeScript
- Trailing commas
- Conventional Commits: feat:, fix:, refactor:, chore:, docs:
- Nunca commitar .env, credenciais ou secrets
- Nunca usar console.log em produção (apenas warn/error)

Skills — workflows sob demanda

Skills são workflows completos carregados apenas quando o usuário invoca. Diferente de rules (que são automáticas), skills precisam ser chamadas explicitamente.

Estrutura de arquivos

.claude/
├── skills/
│   ├── commit/
│   │   └── SKILL.md
│   ├── review-pr/
│   │   └── SKILL.md
│   ├── deploy/
│   │   └── SKILL.md
│   ├── generate-tests/
│   │   └── SKILL.md
│   └── migrate-db/
│       └── SKILL.md

Formato de uma skill

# .claude/skills/commit/SKILL.md

## Description
When the user says "commit", "faz commit", "/commit", or stages changes.

## Trigger
Auto-triggers when staging changes or when user explicitly invokes.

## Steps
1. Run `git status` to see all changes
2. Run `git diff --cached` to see staged changes
3. Run `git log --oneline -5` to understand commit style
4. Analyze the nature of changes:
   - New feature → feat(scope): description
   - Bug fix → fix(scope): description
   - Refactor → refactor(scope): description
   - Documentation → docs(scope): description
   - Configuration → chore(scope): description
5. Draft commit message:
   - Subject ≤ 50 chars
   - Body only when "why" isn't obvious
   - Follow Conventional Commits format
6. Run pre-commit checks:
   - pnpm lint:fix
   - pnpm format
   - pnpm vitest run
7. If all pass, stage and commit
8. If any fail, fix and retry from step 6

Skill com recursos externos

Skills podem incluir templates, scripts e referências:

.claude/skills/deploy/
├── SKILL.md              # Instruções
├── deploy-checklist.md   # Checklist de deploy
└── scripts/
    └── pre-deploy.sh     # Script de verificação
# .claude/skills/deploy/SKILL.md

## Description
When the user says "deploy", "faz deploy", "/deploy".

## Steps
1. Read @.claude/skills/deploy/deploy-checklist.md
2. Verify each item in the checklist
3. Run: bash .claude/skills/deploy/scripts/pre-deploy.sh
4. If all checks pass, run: pnpm build && vercel --prod
5. Notify user of deployment URL

Skills mais úteis

SkillGatilhoO que faz
commit"commit", "/commit"Analisa diff, gera mensagem, roda checks
review-pr"review PR", "/review"Analisa diff, comenta por arquivo
deploy"deploy", "/deploy"Checklist + build + deploy
generate-tests"gerar testes", "/test"Lê módulo, gera testes Vitest
migrate-db"migrar banco", "/migrate"Gera migration up + down
fix-ci"CI quebrou", "/fix-ci"Lê logs do CI, identifica falha, corrige

Interação entre os 3 mecanismos

┌──────────────────────────────────────────────────────────┐
│                    CICLO DE VIDA                         │
│                                                          │
│  Usuário abre sessão                                     │
│  ├── CLAUDE.md carregado (regras globais do projeto)     │
│  ├── .claude/rules/global.md carregado                   │
│  │                                                       │
│  Usuário: "edite src/api/users.ts"                       │
│  ├── .claude/rules/frontend.md carregado (path match)    │
│  ├── .claude/rules/database.md carregado (path match)    │
│  ├── IA edita o arquivo                                  │
│  ├── HOOK onEdit: pnpm lint:fix (executado)              │
│  │                                                       │
│  Usuário: "commit"                                       │
│  ├── SKILL commit/ carregado sob demanda                 │
│  ├── Skill executa: git status, git diff                 │
│  ├── Skill gera mensagem de commit                       │
│  ├── HOOK onCommit: pnpm vitest run (executado)          │
│  ├── Se testes passam → commit feito                     │
│  └── Se testes falham → IA corrige → hook roda de novo   │
└──────────────────────────────────────────────────────────┘

Precedência

Quando há conflito entre mecanismos:

  1. Hooks sempre vencem — são comandos shell, não instruções
  2. Rules path-scoped sobrescrevem CLAUDE.md para arquivos específicos
  3. Skills adicionam contexto, não sobrescrevem nada
  4. CLAUDE.md do projeto sobrescreve CLAUDE.md do usuário
  5. Managed policy (org-wide) sobrescreve tudo

Checklist de configuração

# 1. Criar estrutura
mkdir -p .claude/rules .claude/skills/commit .claude/skills/review-pr

# 2. CLAUDE.md na raiz
cat > CLAUDE.md << 'EOF'
# Project
## Commands: pnpm dev, pnpm lint:fix, pnpm vitest run
## Rules: Vitest never Jest, Conventional Commits
EOF

# 3. Rules globais
cat > .claude/rules/global.md << 'EOF'
---
# Sem paths = sempre carregado
---
2-space indent, single quotes, trailing commas.
Never commit .env or secrets.
EOF

# 4. Rules por stack
# (crie backend.md, frontend.md, tests.md conforme seu projeto)

# 5. Hooks
cat > .claude/settings.json << 'EOF'
{
  "hooks": {
    "onEdit": "pnpm lint:fix",
    "onCommit": "pnpm vitest run && pnpm build"
  }
}
EOF

# 6. Skill de commit
cat > .claude/skills/commit/SKILL.md << 'EOF'
## Description
When the user says "commit" or stages changes.
## Steps
1. git status && git diff --cached
2. Draft Conventional Commit message
3. Run pnpm lint:fix && pnpm vitest run
4. If green, commit
EOF

# 7. Adicionar ao .gitignore (se necessário)
echo ".claude.local.md" >> .gitignore

Conteúdo Relacionado

On this page