Skills Claude Code: crie comandos para a rotina da equipe

Um comando útil para a equipe define as entradas, as evidências a examinar e o formato da resposta. Pense nele como uma ordem de serviço guardada junto do código. Digitar o nome do comando preenche essa ordem para a tarefa da vez.

Comece com /plan, /diff, /context e /compact. Depois, adicione o /team-pr-check dos modelos abaixo. A revisão de código é um bom ponto de partida: as mesmas perguntas sobre permissões, dados e testes aparecem a cada alteração.

Comandos Claude Code que vale conhecer

Digite estes comandos no início de uma mensagem dentro do Claude Code. Colchetes indicam argumentos opcionais; os sinais de menor e maior delimitam argumentos obrigatórios. Esta seleção preserva a sintaxe da referência de comandos atual da Anthropic, consultada em 13 de outubro de 2026. A disponibilidade varia conforme a plataforma, o plano e o ambiente.

Use /compact para continuar o mesmo trabalho e /clear ao mudar de tarefa. Para uma funcionalidade em andamento, uma instrução útil é /compact keep the acceptance criteria, unresolved risks, and exact test commands.

O /release-notes abre o changelog do Claude Code. Ele não redige as notas de versão da sua aplicação. Por isso, o comando personalizado abaixo usa outro nome.

Para incorporar esses controles à rotina, consulte as boas práticas do Claude Code.

As skills incluídas também aparecem no menu de comandos

Algumas entradas do menu de barra entregam ao Claude um procedimento a seguir. São skills incluídas no produto, diferentes dos controles fixos da CLI:

• /code-review revisa um diff ou outro alvo compatível. /review é um alias dele. Adicionar --fix solicita alterações; adicionar --comment solicita a publicação de comentários de revisão.
• /simplify revisa o código alterado para identificar melhorias e aplica correções.
• /verify compila e executa a aplicação para verificar seu comportamento.
• /doctor diagnostica problemas de configuração e propõe correções.

Escolha uma revisão simples quando quiser ver os achados antes de alterar o código. A sintaxe completa, os pré-requisitos e a disponibilidade desses comandos estão nas entradas de skills incluídas na referência de comandos.

Skills Claude Code: o formato dos comandos personalizados

Para novos procedimentos, salve um arquivo Markdown de instruções em .claude/skills/<name>/SKILL.md no repositório. Faça o commit para que toda a equipe receba o mesmo procedimento. Guarde os procedimentos pessoais em ~/.claude/skills/<name>/SKILL.md.

O formato antigo, .claude/commands/<name>.md, continua funcionando. Os dois formatos criam comandos /<name>. O diretório de uma skill também pode conter modelos, documentos de referência e scripts. Prefira esse formato conforme o procedimento crescer. Guia de skills da Anthropic

De onde vêm os comandos de plugins e MCP?

Plugins reúnem recursos para reutilização. Suas pastas skills/<name>/SKILL.md criam comandos com namespace, como /plugin-name:skill-name. Os comandos de plugins no formato antigo ficam em commands/. Essas pastas devem ficar na raiz do plugin, ao lado do diretório .claude-plugin/ que contém o manifesto, e não dentro dele. Use /plugin para gerenciar plugins e /reload-plugins depois de fazer alterações. Componentes de plugins

Comece com skills do projeto enquanto o processo pertencer a uma única base de código. Considere um plugin quando precisar manter e distribuir o mesmo processo em vários repositórios. O guia dos melhores plugins para Claude Code apresenta pacotes existentes que vale avaliar antes de criar outro.

Prompts MCP vêm de servidores conectados. MCP, o Model Context Protocol, conecta o Claude Code a ferramentas e dados externos. Um servidor também pode disponibilizar prompts reutilizáveis. O menu os exibe como /servername:promptname (MCP); /mcp__servername__promptname também os invoca. Eles só aparecem quando o servidor conectado disponibiliza esses prompts. Uma integração que oferece ferramentas não fornece automaticamente todos os prompts de que você possa precisar. Documentação de prompts MCP

Os argumentos de prompts MCP são separados por espaços em branco e seguem os parâmetros declarados pelo servidor. O resultado do prompt entra na conversa. Não presuma que um prompt de servidor trata argumentos da mesma forma que uma skill local.

Crie o arquivo e passe as entradas da tarefa

Frontmatter é o pequeno bloco de configurações YAML que vem antes das instruções em Markdown. A abertura --- precisa estar na primeira linha do arquivo. Os campos abaixo cobrem os modelos deste artigo:

allowed-tools concede permissões; ele não restringe o uso apenas às ferramentas listadas. Todos os campos do frontmatter são opcionais; recomenda-se preencher description. Os arquivos de comandos antigos aceitam os mesmos campos, exceto name e paths. Referência de frontmatter

Argumentos: $ARGUMENTS insere todo o texto de entrada. $0 ou $ARGUMENTS[0] representa o primeiro argumento; $1, o segundo. Os argumentos nomeados correspondem às posições na ordem declarada. Coloque entre aspas um valor posicional com várias palavras. argument-hint documenta as entradas; o procedimento ainda precisa verificá-las. Substituição de argumentos

Os modelos omitem name, então o nome vem da pasta. Seu frontmatter também funciona no formato antigo de arquivo de comando. Guarde informações duradouras sobre o repositório na memória da equipe em CLAUDE.md e os passos de uma tarefa específica na respectiva skill.

Cinco comandos personalizados para copiar e usar na equipe

Crie cada pasta indicada abaixo e cole o bloco correspondente em SKILL.md. Execute /reload-skills para buscar os novos arquivos. Estes são modelos originais para você adaptar, não comandos incluídos pela Anthropic nem resultados alegadamente obtidos em testes.

A ordem abaixo prioriza verificações de engenharia repetíveis e, depois, comunicação. Os modelos usam evidências locais do repositório sempre que possível. Eles não exigem conexão com um gerenciador de issues ou serviço de PRs para produzir um resultado útil.

Checklist de revisão de PR para alterações que envolvem dados de clientes

Uma equipe pequena de SaaS pode usar este comando antes de solicitar revisão humana. Ele repete as verificações de isolamento entre tenants, autorização e cobertura de testes mesmo quando o autor está com pressa. O valor está em entregar uma revisão mais consistente, com cada achado vinculado a um ponto do código e a um cenário de falha.

Salve em .claude/skills/team-pr-check/SKILL.md. Execute /team-pr-check main para revisar a branch atual em relação à sua base de merge com main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

Um checklist merece espaço quando reflete as falhas que realmente ocorrem no seu produto. Substitua verificações genéricas pelos limites que importam, como a titularidade de contas, o estado de cobrança ou as permissões herdadas de equipes.

Correção de bug reproduzível começando pelo teste

Um fundador que mantém um produto em produção pode usar este comando quando há uma forma concreta de reproduzir o bug relatado. Ele inclui o comportamento com falha e a verificação de regressão na ordem de serviço, para que a entrega não se resuma a um patch que apenas parece correto.

Salve em .claude/skills/team-test-first-fix/SKILL.md. Execute /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

Esse procedimento serve para defeitos reproduzíveis. Em um incidente intermitente de produção sem evidências suficientes, comece pela investigação, em vez de forçar o comando a inventar um teste que falhe.

Plano de migração antes de mexer em um sistema compartilhado

Uma equipe que altera um esquema de banco de dados ou substitui uma API pode usar este comando para levantar questões de sequência e compatibilidade antes da implementação. O resultado útil é um plano que possa ser questionado, principalmente quando versões antigas e novas precisam funcionar ao mesmo tempo.

Salve em .claude/skills/team-migration-plan/SKILL.md. Execute /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

A instrução para planejar não altera o modo de permissão do Claude Code. Se também quiser colocar a sessão no Plan Mode, digite /plan antes de invocar a skill. Trate o procedimento escrito e as permissões das ferramentas da sessão como controles separados. Plan Mode

Notas de versão do seu produto

Um desenvolvedor responsável pelos lançamentos pode usar este comando para transformar um intervalo definido de alterações em um rascunho voltado aos clientes. Ele reduz o trabalho de traduzir commits em impacto para o usuário e exige evidências para cada afirmação.

Salve em .claude/skills/team-release-notes/SKILL.md. Execute /team-release-notes previous-release HEAD, substituindo previous-release por uma tag ou um commit existente.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

Um intervalo de código comprova o que mudou no repositório. Ele não comprova quais clientes receberam a alteração. Confirme o status da liberação antes de publicar o rascunho.

Changelog semanal para a equipe

Uma liderança de engenharia pode usar este comando para preparar a atualização semanal para as equipes de produto e suporte. Ele separa o trabalho já integrado das liberações verificadas, evitando anunciar por engano algo que ainda depende de uma flag.

Salve em .claude/skills/team-weekly-changelog/SKILL.md. Execute /team-weekly-changelog START_DATE END_DATE main, substituindo as datas por timestamps ISO com fuso horário. O intervalo inclui o início e exclui o fim.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Mantenha as notas de versão separadas das atualizações semanais. Uma versão tem limites de código definidos e se dirige aos clientes. Uma atualização semanal cobre um período de acompanhamento e pode incluir trabalho útil que ainda não foi lançado.

Como saber se vale a pena manter um comando?

Meça o trabalho repetitivo que cerca o uso do modelo, não o quanto a primeira resposta impressiona.

O cálculo do valor semanal é: execuções × (tempo anterior de preparação e correção − novo tempo de preparação e correção) × custo por hora da equipe − gasto adicional com o modelo − tempo de manutenção convertido em custo por hora da equipe. Preencha a conta com suas próprias medições. Um prompt mais longo que exige mais revisão pode dar prejuízo, mesmo que pareça mais automatizado.

O custo com maior chance de mudar é o tempo de desenvolvedores seniores gasto explicando o mesmo processo e corrigindo entregas incompletas. O procedimento ainda precisa de manutenção quando a arquitetura ou o processo de lançamento muda.

Um comando salvo também consome uso do modelo quando o Claude segue suas instruções. /usage informa estimativas de custo de tokens e dados de uso do plano; uma estimativa exibida de custo de API não é uma fatura de assinatura. Documentação de custos da Anthropic

Duas oportunidades de negócio a partir desses comandos

Os modelos são ferramentas internas úteis. Para transformá-los em produto, é preciso oferecer uma vantagem mais difícil de reproduzir do que simplesmente salvar um prompt.

A melhor oportunidade: verificações de revisão específicas do repositório

Uma pequena equipe de software poderia pagar por um pacote de revisão mantido continuamente e que conhecesse seus pontos de maior risco: quais tabelas pertencem a uma conta, quais ações afetam a cobrança e quais testes devem acompanhar uma alteração.

A consulta de palavras-chave do DataForSEO para o Google dos Estados Unidos, em inglês, retornou 1,300 buscas mensais estimadas por “ai code review” em 13 de outubro de 2026. Isso indica interesse na tarefa, não demanda por um plugin específico do Claude Code. Visão geral de palavras-chave do DataForSEO

A menor versão comercializável poderia combinar um checklist do projeto, notas de arquitetura de apoio e um conjunto de bugs anteriores para avaliação. Antes de distribuí-la como plugin, faça com que produza achados sustentados por evidências nesses exemplos.

O obstáculo é a concorrência forte: o Claude Code já inclui recursos de revisão, e a CodeRabbit vende ferramentas de revisão de código. Um prompt genérico de revisão oferece pouca diferenciação. Eu só escolheria essa oportunidade com acesso ao histórico de falhas de uma equipe específica e com alguém responsável por manter as verificações corretas.

Uma oportunidade menor: comunicação de lançamentos com evidências

Uma equipe de produto poderia usar um fluxo de trabalho mantido continuamente que transforme alterações do repositório em notas de versão para clientes e em um informe interno para o suporte, com referências às fontes e uma verificação explícita do status da liberação.

A mesma consulta de palavras-chave retornou 70 buscas mensais estimadas por “release notes generator”. É um sinal modesto de procura, então eu começaria com um serviço ou fluxo de trabalho interno antes de desenvolver um software independente. Visão geral de palavras-chave do DataForSEO

A versão mais simples poderia gerar rascunhos a partir de um intervalo Git escolhido, no formato já adotado pela equipe. A parte difícil é relacionar as alterações a flags, implantações e disponibilidade real para os clientes. O comando pode organizar evidências; ele não pode fabricar as que a equipe não registra.

Os limites que importam em um repositório de negócio

Um comando padroniza instruções. Seus testes, revisões e controles de lançamento continuam determinando se o resultado é aceitável. Trate os cinco modelos como procedimentos iniciais e revise suas alterações junto com o código da aplicação.

O conteúdo completo de uma skill é carregado quando ela é usada. Por isso, mantenha o procedimento conciso e coloque as referências detalhadas em arquivos de apoio. Skills pessoais podem ter precedência sobre skills do projeto com o mesmo nome; skills também podem se sobrepor a comandos nativos em sessões locais de terminal. Use nomes distintos e examine a origem quando pessoas da equipe obtiverem comportamentos diferentes. Carregamento e precedência de skills

Configure separadamente as regras que de fato controlam as permissões das ferramentas. Uma frase como “apenas revise” comunica ao Claude sua intenção; ela não é uma restrição do sistema operacional. Permissões do Claude Code

Por onde começar na segunda-feira

Faça primeiro o commit de /team-pr-check. Substitua os itens genéricos pelas verificações que sua última alteração problemática deveria ter passado. Execute o comando em uma alteração concluída cujo resultado você conhece, compare os achados com o problema real e ajuste o procedimento antes de incorporá-lo à rotina da equipe. Adicione os comandos de notas de versão e atualização semanal quando os formatos de saída estiverem combinados.

Se você quer conectar esses fluxos de trabalho aos sistemas do seu negócio, eu desenvolvo automações com IA a partir das verificações de que sua equipe realmente precisa.