Visão geral
O que o overpower é, as três perguntas que os três comandos respondem, e por que a versão que você fixa é o catálogo que você recebe.
O overpower é uma CLI que instala equipamento de agente já curado, skills,
servidores MCP e frameworks inteiros deles, dentro de um repositório ou numa
máquina. Ele não faz scaffold, não gera nada e não pergunta nada a um LLM. Ele
copia arquivos que alguém já decidiu que valem a pena, e enxerta configuração
que um runtime já sabe ler.
Instalar em cinco passos
Rodar sem instalar
O
uvxbaixa o pacote num ambiente efêmero, roda e joga o ambiente fora. Nada sobra na máquina além do que o própriooverpowerescreveu.uvx overpower@latest --versionVer o que existe
O catálogo sai em quatro blocos, cada entrada com o tamanho, a contagem de arquivos e a descrição por inteiro.
uvx overpower@latest listLer o plano antes de escrever
O
--dry-runresolve tudo, imprime todo destino e quem o lê, espelha o código de saída real e não encosta em disco.uvx overpower@latest install --skill panlabs-python-standards --runtime claude-code --dry-runEscrever
Num terminal, o comando pergunta antes de escrever. Fora de um terminal ele nunca pergunta, então a mesma linha se comporta igual dentro de um script.
uvx overpower@latest install --skill panlabs-python-standards --runtime claude-codeConferir que continua de pé
O
doctorresponde se o que foi escrito continua sendo o que foi escrito, e sai3quando acha problema.uvx overpower@latest doctor
Os três comandos, e o que cada um responde
Toda invocação do overpower responde a uma de exatamente três perguntas.
| Comando | Pergunta | Resposta |
|---|---|---|
list | O que existe? | O catálogo, ou o conteúdo inteiro de um item dele. |
install | Escreva. | Um plano, impresso antes de qualquer escrita, e depois a escrita. |
doctor | Continua sendo o que era? | Um relatório sobre o terminal e sobre a integridade do que foi instalado. |
Digitado nu, o overpower imprime a marca e a ajuda de topo, e sai 0. Sob um
cano a marca cai e só a ajuda passa, então um grep ou um redirecionamento
recebe algo que vale a leitura.
--version lê a versão dos metadados do pacote instalado, e não de uma
constante fixada no código. É por isso que ele serve de prova de que o pacote
chegou inteiro, em vez de ser só um texto que estava lá dentro.
O primeiro uso, fim a fim
Três linhas, na ordem, e cada uma responde uma coisa. Rode dentro de um repositório git.
# 1. o que existe para instalar
uvx overpower@latest list
# 2. o plano, sem escrever nada
uvx overpower@latest install --skill panlabs-python-standards \
--runtime claude-code --dry-run
# 3. a escrita, com a confirmação que ela pede
uvx overpower@latest install --skill panlabs-python-standards \
--runtime claude-code
O passo 2 é o que faz o 3 ser sem surpresa: o --dry-run resolve tudo, imprime
todo destino e quem o lê, espelha o código de saída real e não escreve nada, nem
um diretório vazio. O que ele imprimir é o que o passo 3 escreve.
O passo 2 imprime o plano, e nada mais acontece:
_____ _____ _ __ _ __ _____ _____ _ __
/ _ \ \ / / _ \ '__| '_ \ / _ \ \ /\ / / _ \ '__|
| (_) \ V / __/ | | |_) | (_) \ V V / __/ |
\___/ \_/ \___|_| | .__/ \___/ \_/\_/ \___|_|
|_|
installs curated agent equipment v0.27.3
╭─ plan ───────────────────────────────────────────────────╮
│ │
│ panlabs-python-standards 1 skill │
│ │
│ skill panlabs-python-standards │
│ │
│ .claude/skills/ ← claude-code 8 files │
│ │
╰──────────────────────────────────────────────────────────╯
dry run nothing was written
Cada linha de destino diz para onde o equipamento vai e qual runtime lê aquele caminho. O passo 3 repete esse resumo, escreve, e fecha dizendo o que aterrissou:
_____ _____ _ __ _ __ _____ _____ _ __
/ _ \ \ / / _ \ '__| '_ \ / _ \ \ /\ / / _ \ '__|
| (_) \ V / __/ | | |_) | (_) \ V V / __/ |
\___/ \_/ \___|_| | .__/ \___/ \_/\_/ \___|_|
|_|
installs curated agent equipment v0.27.3
┌ overpower install
│
◇ summary ────────────────────────────────────────────────╮
│ │
│ panlabs-python-standards 1 skill │
│ │
│ .claude/skills/ ← claude-code 8 files │
│ │
├──────────────────────────────────────────────────────────╯
│
◇ installed ──────────────────────────────────────────────╮
│ │
│ ✓ panlabs-python-standards 1 skill │
│ .claude/skills/ │
│ │
│ 1 write · 8 files │
│ │
├──────────────────────────────────────────────────────────╯
│
└ Done! Review what landed before use; it runs with full
agent permission.
Depois, a conferência:
uvx overpower@latest doctor
Ele sai 0 quando as cinco conferências passam e 3 quando alguma acha
problema, e nunca 1 por relatório ruim. É isso que o torna encadeável numa
esteira:
uvx overpower@latest install --skill panlabs-python-standards \
--runtime claude-code --yes && uvx overpower@latest doctor
Se você omitir o --runtime num terminal, a linha não recusa: ela abre o
assistente no passo que faltou. Num cano, a mesma linha sai 2. A diferença
está em Comandos.
Manter a versão em dia com @latest
O catálogo não é buscado pela rede nem na instalação nem na execução. Ele vem
embutido no pacote, e o list o lê andando pelo sistema de arquivos. Disso
sai uma consequência fácil de perder de vista: a versão do overpower é a
versão do catálogo que ele carrega. Não existe versão de catálogo separada para
acompanhar, e não existe jeito de receber catálogo novo sem receber overpower
novo.
O uvx complica isso de um jeito específico. Rodado como uvx overpower, sem
fixar versão, ele resolve o último lançamento na primeira invocação e guarda
essa resolução sem prazo de validade. Um uvx overpower hoje e o mesmo uvx overpower daqui a seis meses podem rodar exatamente o mesmo build, e servir
exatamente o mesmo catálogo. Catálogo que nunca envelhece seria curiosidade;
catálogo cujo envelhecimento é invisível é defeito.
uvx overpower@latest list
Fixar @latest é o que quebra esse cache a cada invocação. Toda linha deste site
o traz, e não por estilo de casa copiado de outro README, e sim porque é a única
grafia que mantém o catálogo que você recebe igual a o catálogo que existe.