khasky

Padrões de design de API REST: nomeação de recursos, códigos de status, paginação, filtragem, erros, versionamento e limitação de taxa. Utilize ao projetar ou revisar APIs.

Documenta e mantém variáveis de ambiente e configurações (ex: .env.example). Utilize ao configurar, durante a integração de novos usuários, ou quando o usuário solicitar a documentação das variáveis de ambiente ou o arquivo .env.example.

Gera changelogs e notas de lançamento a partir de commits e tags. Utilize ao lançar uma versão, escrever notas de lançamento ou manter um CHANGELOG.

Atualiza dependências com segurança e revisa mudanças que podem quebrar o código. Use ao atualizar pacotes, resolver vulnerabilidades ou quando o usuário pedir para atualizar dependências.

Gera mensagens de commit convencionais a partir de diffs do git. Use ao escrever mensagens de commit, resumir alterações preparadas ou quando o usuário menciona commits ou changelog.

Revisa código para correção, segurança e padrões da equipe, sendo útil para pull requests, diffs ou revisões de código solicitadas pelo usuário em qualquer linguagem ou projeto.

Padrões universais de codificação, nomenclatura, estrutura e padrões para código consistente. Use ao iniciar um projeto, refatorar, configurar lint/format ou aplicar convenções.

Estratégias de implantação, segurança de lançamento, verificações de saúde e rollback. Use ao projetar ou documentar implantação/rollback, CI/CD ou prontidão para produção, aplicável a qualquer stack ou plataforma.

Exige a execução de comandos de verificação e a confirmação da saída antes de declarar o trabalho como completo, corrigido ou aprovado. Use antes de fazer commits, criar PRs ou marcar tarefas como concluídas, aplicando-se a qualquer linguagem, executor de testes ou sistema de build.

Escreve testes antes da implementação usando o ciclo red-green-refactor. Use ao implementar funcionalidades ou corrigir bugs, ou quando o usuário solicitar TDD.

Aplica tratamento de erros consistente, registro de logs e mensagens para o usuário. Use ao adicionar ou refatorar o tratamento de erros, ou quando o usuário solicitar padrões de tratamento de erros.

Responda ao feedback de revisão de código verificando antes de implementar, esclarecendo itens pouco claros e contestando com raciocínio técnico quando necessário. Isso se aplica a qualquer equipe ou cultura ao receber feedback de PR ou comentários de revisão.