Automação com Hooks, Rules e Skills — Gatilhos no Workflow de IA
Baixar PDFComo 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
| Mecanismo | Gatilho | O que faz | Granularidade |
|---|---|---|---|
| Hooks | Evento do ciclo de vida (edit, commit, finish) | Executa comandos shell | Global (todo o projeto) |
| Rules | Caminho do arquivo sendo editado | Injeta instruções no contexto | Path-scoped (por diretório) |
| Skills | Comando do usuário ou frase de gatilho | Carrega workflow completo | Demand-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
| Gatilho | Quando dispara | Caso de uso |
|---|---|---|
onEdit | Após cada edição de arquivo | Lint, format, typecheck |
onSave | Quando arquivo é salvo | Formatação automática |
onCommit | Antes de cada commit | Testes, build, security scan |
onFinish | Quando sessão termina | Build final, notificação |
onError | Quando comando falha | Log, 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é passarHooks 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 handlersComo 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 APIRule 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.mdFormato 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 6Skill 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 URLSkills mais úteis
| Skill | Gatilho | O 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:
- Hooks sempre vencem — são comandos shell, não instruções
- Rules path-scoped sobrescrevem CLAUDE.md para arquivos específicos
- Skills adicionam contexto, não sobrescrevem nada
- CLAUDE.md do projeto sobrescreve CLAUDE.md do usuário
- 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" >> .gitignoreConteúdo Relacionado
Cursor em Profundidade — Composer 2, Agentes e Cloud
Guia completo do Cursor IDE: Composer 2 com planning, agentes autônomos, cloud agents, @-mentions, rules, configuração avançada e comparação com Claude Code.
Workflow Prático — Claude Code e Cursor na Produção
Passo a passo para configurar e usar Claude Code e Cursor em projetos reais. Setup, CLAUDE.md, skills, hooks, orquestração de subagentes e o loop de desenvolvimento diário.