release

Skill de Release

Um assistente de release leve e consciente do repositório. Na primeira execução inspeciona o projeto e a CI para derivar regras de release, armazena-as em .omc/RELEASE_RULE.md para uso futuro e, em seguida, guia você por uma release usando essas regras.

Uso

/oh-my-claudecode:release [versão]

• versão é opcional. Se omitido, a skill perguntará. Aceita patch, minor, major ou um semver explícito como 2.4.0.
• Adicione --refresh para forçar uma reanálise do repositório mesmo quando um arquivo de regras em cache existir.

Fluxo de Execução

Passo 0 — Carregar ou Construir Regras de Release

Verifique se .omc/RELEASE_RULE.md existe.

Se NÃO existir (ou --refresh foi passado): Execute a análise completa do repositório abaixo e escreva o arquivo.

Se existir: Leia o arquivo. Em seguida, faça uma verificação delta rápida — analise .github/workflows/ (ou diretórios de CI equivalentes: .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml) para quaisquer modificações mais recentes que o timestamp last-analyzed no arquivo de regras. Se arquivos de workflow relevantes foram alterados, reexecute a análise para essas seções e atualize o arquivo. Relate o que mudou.

---

Passo 1 — Análise do Repositório (primeira execução ou --refresh)

Inspecione o repositório e responda às perguntas a seguir. Escreva as respostas em .omc/RELEASE_RULE.md.

1a. Fontes de Versão

• Localize todos os arquivos que contêm uma string de versão correspondente à versão atual em package.json / pyproject.toml / Cargo.toml / build.gradle / arquivo VERSION / etc.
• Liste cada arquivo e o campo ou padrão regex usado para encontrar a versão.
• Detecte se existe um script de automação de release (ex.: scripts/release.*, target Makefile release, bump2version, release-it, semantic-release, changesets, goreleaser).

1b. Registro / Distribuição

• npm (package.json com publishConfig ou npm publish na CI), PyPI (pyproject.toml + twine/flit), Cargo (Cargo.toml), Docker (Dockerfile + passo push), GitHub Packages, outros.
• Existe um passo na CI que publica automaticamente ao push de tag? Qual arquivo de workflow e job?

1c. Gatilho de Release

• Identifique o que inicia a release: push de tag (v*), dispatch manual (workflow_dispatch), merge para main/master, merge de branch de release, padrão de mensagem de commit.

1d. Gate de Testes

• Identifique o comando de teste e onde ele é executado na CI.
• Os testes precisam passar antes da publicação? Anote quaisquer flags de bypass.

1e. Notas de Release / Changelog

• Existe um CHANGELOG.md ou CHANGELOG.rst?
• Qual convenção é usada: Keep a Changelog, Conventional Commits, gerado automaticamente pelo GitHub, nenhuma?
• Existe um arquivo de corpo de release (ex.: .github/release-body.md) commitado antes da tag?

1f. Verificação de Primeiro Uso

• Existe um workflow de release em .github/workflows/ (ou equivalente)? Se não, sinalize e ofereça-se para criar um scaffold.
• Existe uma entrada no .gitignore impedindo que artefatos de build sejam commitados? Se não, sinalize.
• Tags git estão sendo usadas? Execute git tag --list para verificar. Se não existirem tags, sinalize e explique a melhor prática.

---

Passo 2 — Escrever .omc/RELEASE_RULE.md

Crie ou sobrescreva o arquivo com esta estrutura:

# Regras de Release
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->

## Fontes de Versão
<!-- lista de arquivos + padrões -->

## Gatilho de Release
<!-- o que inicia a release -->

## Gate de Testes
<!-- comando + nome do job na CI -->

## Registro / Distribuição
<!-- npm, PyPI, Docker, etc. + job da CI que publica -->

## Estratégia de Notas de Release
<!-- convenção + arquivos -->

## Arquivos de Workflow da CI
<!-- caminhos para arquivos de workflow relevantes -->

## Lacunas de Configuração Inicial
<!-- quaisquer itens faltando encontrados durante a análise, ou "nenhuma" -->

---

Passo 3 — Determinar Versão

Se o usuário forneceu um argumento de versão, use-o. Caso contrário:

1. Mostre a versão atual (do arquivo de versão principal).
2. Mostre o que patch, minor e major produziriam.
3. Pergunte ao usuário qual usar.

Valide que a versão escolhida é uma string semver válida.

---

Passo 4 — Checklist Pré-Release

Apresente um checklist derivado das regras de release. No mínimo:

• Todas as alterações destinadas a esta release foram commitadas e enviadas (push)
• A CI está verde na branch alvo
• Testes passam localmente (execute o comando do gate de testes)
• Bump de versão aplicado a todos os arquivos fonte de versão
• Notas de release / changelog preparados (veja Passo 5)

Peça ao usuário para confirmar antes de prosseguir, ou execute cada passo se ele disser "pode ir".

---

Passo 5 — Orientação para Notas de Release

Ajude o usuário a escrever boas notas de release. Aplique a convenção que o repositório usa. Orientação padrão quando nenhuma convenção é detectada:

O que torna uma nota de release boa:

• Comece com o que mudou para os usuários, não detalhes de implementação interna.
• Agrupe por tipo: Novas Funcionalidades, Correções de Bugs, Alterações que Quebram Compatibilidade, Depreciações, Interno / Tarefas.
• Para cada item: uma frase, link para o PR ou issue, credite o autor se externo.
• Alterações que quebram compatibilidade vão primeiro e devem incluir um caminho de migração.
• Omita alterações que os usuários nunca veem (refatorações, ajustes de CI, alterações apenas de teste), a menos que afetem a reprodutibilidade do build.

Exemplo de formato de entrada:

### Correções de Bugs
- Corrige queda de sessão na expiração do token (#123) — @contribuidor

Se o repositório usa Conventional Commits, gere um rascunho de changelog a partir de git log <tag-anterior>..HEAD --no-merges --format="%s" agrupado por tipo de commit. Mostre ao usuário e deixe-o editar.

---

Passo 6 — Executar Release

Usando as regras descobertas, percorra:

1. Bump de versão — aplique a cada arquivo fonte de versão.
2. Executar testes — execute o comando do gate de testes.
3. Commit — git add <arquivos de versão> CHANGELOG.md e commit com chore(release): bump version to vX.Y.Z.
4. Tag — git tag -a vX.Y.Z -m "vX.Y.Z" (tags anotadas são preferíveis a leves).
5. Push — git push origin <branch> && git push origin vX.Y.Z.
6. CI assume o controle — se o gatilho de release for push de tag, lembre o usuário de que a CI cuidará do restante (publicação, criação de GitHub Release). Mostre o arquivo de workflow da CI esperado.
7. Publicação manual — se não existir automação de CI, liste o comando de publicação manual (ex.: npm publish --access public, twine upload dist/*).

---

Passo 7 — Sugestões de Configuração Inicial

Se lacunas foram encontradas no Passo 1f, ofereça ajuda concreta:

Nenhum workflow de release:

Seu repositório não tem um workflow de CI de release. Um workflow do GitHub Actions acionado por push de tag v* é a prática mais comum. Ele pode:

• Executar testes
• Publicar no npm/PyPI/etc.
• Criar uma GitHub Release com suas notas de release

Quer que eu crie um scaffold de .github/workflows/release.yml para sua stack?

Nenhuma tag git:

Esta parece ser a primeira release. Tags git permitem que o GitHub, npm e outras ferramentas entendam seu histórico de versões. Criaremos sua primeira tag no Passo 6.

Artefatos de build não adicionados ao .gitignore:

Artefatos de build estão presentes no histórico do git ou não estão no .gitignore. Isso infla o tamanho do repositório e cria conflitos de merge. Quer que eu os adicione ao .gitignore?

---

Passo 8 — Verificar

Após o push:

• Verifique o status da CI: gh run list --workflow=<workflow de release> --limit=3 (se gh estiver disponível).
• Verifique o registro (npm, PyPI) pela nova versão após alguns minutos.
• Confirme se uma GitHub Release foi criada: gh release view vX.Y.Z.

Relate sucesso ou sinalize quaisquer falhas.

---

Notas

• Esta skill não codifica comandos ou arquivos de versão específicos do projeto. Tudo é derivado da inspeção do repositório.
• .omc/RELEASE_RULE.md é um cache local. Faça commit dele no seu repositório se quiser compartilhar as regras derivadas com sua equipe, ou adicione-o ao .gitignore se preferir mantê-lo local.
• Para monorepos complexos ou workspaces de múltiplos pacotes, a skill detectará padrões de workspace (npm workspaces, pnpm workspaces, Cargo workspace) e se adaptará adequadamente.