Stack de Skills Claude Code de um Engenheiro Sênior

Stack de Skills Claude Code de um Engenheiro Sênior

A primeira vez que vi um agente do Claude Code assumir um ticket do Jira, reproduzir o bug em um navegador real, diagnosticá-lo, escrever um teste que falha, criar a correção, dar merge no main e notificar o QA — tudo isso sem eu tocar no teclado entre os passos — senti aquela sensação desconfortável que todo engenheiro em atividade experimenta eventualmente. Não era “isso vai me substituir”. Era mais algo como: “Eu venho fazendo uma versão disso errado há três anos”.

O engenheiro que eu estava observando não era um desses influenciadores de IA no YouTube. Ele era um ex-senior da Amazon e da Microsoft, atualmente lançando um produto chamado BookZ.AI, e construiu o que provavelmente é o stack de habilidades do Claude Code mais disciplinado que já vi em 2026. Oito habilidades. Cada uma resolve um modo específico de falha da experiência “Claude Code bruto”. Combinadas, fazem algo que a documentação dificilmente promove: transformam o Claude Code de um autocomplete inteligente para algo mais próximo de uma equipe de engenharia júnior ou pleno, que por acaso trabalha às 3 da manhã.

Passei o fim de semana desmontando esse stack, instalando as peças e testando tudo em um pequeno SaaS que estou desenvolvendo. Algumas partes entregaram o que prometem. Outras estão supervalorizadas. A habilidade Fixed Ticket realmente me surpreendeu. O stack de marketing — a parte que eu supunha ser puro enfeite — acabou sendo o aspecto mais subestimado de toda a configuração.

Aqui está o detalhamento completo: o que cada habilidade faz, quando eu a usaria, como elas se combinam e os pontos específicos em que a experiência comum do Claude Code desmorona sem elas.

Por que o “Claude Code Bruto” Acaba Quebrando

O Claude Code, por si só, é poderoso. Você aponta para um repositório, descreve o que quer e ele escreve o código. Isso funciona muito bem para um projeto de fim de semana. Começa a desmoronar assim que seu código recebe um segundo colaborador, um deploy em produção e uma base de usuários atenta a bugs.

Os três modos de falha com que sempre esbarro:

1. Ele pula etapas. O Claude Code bruto vai escrever alegremente tanto a feature quanto os testes — mas só se você pedir de forma firme, na ordem certa, e recusar o primeiro rascunho. Se deixado livre, ele deriva para o “código no feeling”: entrega a feature, deixa os testes para depois, refatora ainda mais tarde, e raramente chega a fechar o ciclo.
2. Perde contexto entre sessões. Cada nova sessão começa do zero. Suas convenções de projeto, sua linguagem de design, o histórico de bugs — ele precisa redescobrir tudo isso a partir do CLAUDE.md ou do que você colar ali.
3. Não fecha ciclos. Ele escreve o código, mas será que roda de verdade? O bug ainda acontece? O deploy foi bem-sucedido? Alguém — geralmente eu — precisa ir lá verificar, e é nesta etapa de verificação que a maioria das demonstrações de “IA que entrega código” simplesmente desmorona.

As habilidades que vou detalhar não são truques genéricos de produtividade. Cada uma fecha um ciclo específico. Juntas, fazem o Claude Code se comportar menos como um estagiário hiperativo e mais como um time que realmente entrega.

Se você ainda não construiu o modelo mental sobre o que realmente são habilidades em 2026, meu guia de agent skills para Claude Code cobre a mecânica por trás — este post parte do pressuposto que você já tem essa base e quer ver como é um stack de produção.

Habilidade 1: Superpoderes — A Camada da Disciplina

A habilidade fundamental. Aquela sem a qual as outras sete são apenas formas mais agradáveis de embarcar o caos.

Superpoderes é um plugin open-source do Claude Code criado por obra (Jesse Vincent) que alcançou mais de 99 mil estrelas no GitHub em apenas três meses após o lançamento em janeiro de 2026 — o que é absurdo para um plugin e mostra o quanto há demanda por exatamente esse problema. Ele foi oficialmente aceito no marketplace de plugins da Anthropic logo depois.

O que ele faz, em uma frase: ele faz com que o Claude Code siga um fluxo de trabalho real de engenharia sênior em vez de simplesmente buscar o caminho mais rápido.

O fluxo de trabalho que ele impõe é:

1. Brainstorm — transformar uma solicitação vaga em uma especificação decisória
2. Spec — descrever exatamente o que será construído, e o que está explicitamente fora do escopo
3. Planejar — decompor em tarefas de 2 a 5 minutos, com caminhos de arquivos exatos
4. TDD — red-green-refactor; os testes devem falhar antes da implementação
5. Subagent Dev — cada tarefa é executada em um subagente novo para evitar deriva de contexto em execuções de várias horas
6. Revisão — revisão de código automatizada antes de qualquer coisa ser considerada pronta
7. Finalizar — criação de PR, limpeza de branch, gerenciamento do worktree

A parte inegociável é o ciclo de TDD. O Superpoderes não diz "você pode seguir TDD". Ele diz "você vai seguir TDD", e faz isso por meio da arquitetura da habilidade, não com instruções educadas. Os testes são escritos primeiro. Eles precisam falhar. Só então a implementação é escrita. Se o teste não falhar de fato na fase vermelha, a habilidade marca como falso verde e bloqueia o progresso.

Essa única regra eliminou cerca de 60% dos problemas do tipo "Claude escreveu um código que compila mas não faz o que eu pedi" que eu enfrentava. Porque se o teste foi escrito para o comportamento real desejado, e eu assisti ao teste falhar antes do código ser escrito, ou o código faz o teste passar ou não faz. Não existe meio-termo onde o Claude alucina uma função que retorna algo só mais ou menos correto.

Quando eu uso: literalmente toda sessão que mexe com código de produção. O único caso em que não uso é para scripts descartáveis e notebooks exploratórios, onde o "ritual" custa mais do que compensa.

Se você for instalar apenas uma habilidade desta stack inteira, que seja esta. Todo o resto deste post parte do princípio de que o Superpoderes já está sendo responsável por manter o ciclo de desenvolvimento honesto. Escrevi uma análise detalhada do plugin Superpoderes caso queira se aprofundar especificamente na aplicação de TDD.

Habilidade 2: Criador de Habilidades — A Meta Camada

Aqui está a parte que me confundiu por tempo demais para admitir: Criador de Habilidades é uma habilidade que constrói outras habilidades. Essencialmente, é a fábrica de desenvolvimento de habilidades.

A Anthropic desenvolveu essa funcionalidade. Ela vem com quatro modos de operação: Criar, Avaliar, Aprimorar e Benchmark. Juntos, esses modos cobrem todo o ciclo de vida de uma habilidade — do "tive uma ideia" ao "medi essa habilidade diante de uma carga de trabalho real e agora sei se ela realmente ajuda".

Por que isso importa? Porque o verdadeiro poder do ecossistema de habilidades não está em instalar habilidades de outras pessoas. É compor as suas próprias. O engenheiro sênior responsável pelo BookZ.AI não tratou o Superpowers como a solução definitiva. Ele pegou Superpowers, pegou trechos do GSD (Get Stuff Done), pegou módulos do GStack e construiu uma habilidade customizada e unificada para lidar com o fluxo de trabalho específico dele: seus estágios preferidos, seus frameworks de teste, sua cadência de revisão.

Essa abordagem de compor as próprias habilidades é fundamental porque as habilidades são delimitadas por estágio. Você pode substituir um módulo de brainstorming sem perder a etapa de TDD. Pode adicionar uma fase de revisão personalizada que executa as regras de lint da sua equipe. O modo Eval do Criador de Habilidades permite medir cada versão em um benchmark — "essa versão atualizada realmente produz código melhor na minha base de código real, ou só produz mais código?"

O que a maioria dos tutoriais ignora é o quanto o ciclo de avaliação (Eval loop) é crucial. Escrever uma habilidade é fácil. Escrever uma habilidade que comprovadamente melhora os resultados no seu trabalho é o que separa uma habilidade de brinquedo daquela que você continua usando.

Quando eu recorro a ela: sempre que percebo que estou repetindo o mesmo prompt de 5 ou mais frases em várias sessões. Essa repetição é o sinal — uma nova habilidade está pronta para nascer.

Skill 3: UI/UX ProMax — O Design System Sob Demanda

Este foi o recurso do qual eu mais duvidava. "Habilidade de UI/UX" normalmente significa "dashboard genérico feito no Tailwind". ProMax é o oposto disso.

O banco de dados subjacente, de acordo com a documentação oficial do skill, reúne mais de 50 estilos visuais, 161 paletas de cores, 57 combinações de fontes, 161 tipos de produto, 99 diretrizes de UX e 25 tipos de gráficos distribuídos em 10 stacks-alvo (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, HTML/CSS puro). O skill é acionado automaticamente sempre que a tarefa envolve estrutura de interface, refatoração de componentes, escolha de sistema de cores ou tipografia — não é preciso invocar manualmente.

O ponto que me conquistou: padrões pré-definidos por setor. Você diz "dashboard fintech" e as escolhas de estilo/cor/tipografia do skill já estão restritas ao que dashboards fintech realmente usam — tabelas de alta densidade, paletas sóbrias que funcionam em mesas de operações pouco iluminadas, tipografia monoespaçada em contextos numéricos. Você pede "app de produtividade relaxante" e os padrões caminham para maior contraste, espaçamento generoso e fontes pensadas para não cansar após longos períodos de uso.

ProMax compõe com o padrão "Stitch" do Google, onde você entrega ao skill um arquivo design.md descrevendo a experiência desejada e ele devolve um design system completo: padrões, tokens de cor, pares tipográficos, auditoria de acessibilidade (WCAG AA mínimo por padrão), estrutura SEO meta e orçamentos de performance. O repositório Awesome Design MD no GitHub traz exemplos prontos de design.md para produtos mais comuns — assim, você não começa da página em branco.

O modo de restrição é onde tudo fica realmente prático. Você diz ao ProMax: "mantenha a paleta de cores e a grade de layout existentes, mas redesenhe todo o resto dentro desses limites." E ele respeita isso — não apenas sugerindo mudanças esperando que você perceba, mas estabelecendo constraints rígidas que simplesmente não permite violar. Testei isso em uma landing page: eu adorava o sistema de cores, mas odiava a hero section. O ProMax retornou cinco variantes da hero, todas usando exatamente os tokens existentes. É nesse teste que normalmente as outras ferramentas de design falham.

Quando uso: desenvolvimento de UI do zero, reescrita de landing page ou quando estou prestes a tomar uma decisão de design que vai impactar o resto do produto. Deixo desativado quando estou apenas fazendo ajustes pontuais em um design system já estabelecido — aqui, a opinião do skill não agrega, e chamá-lo só adiciona ruído.

Se você está lendo isso e pensando "mas já tenho o Figma", está tudo ok. O valor aqui não é substituir o Figma. É permitir que o Claude Code tome decisões de design direto no código — em vez de perguntar que cor o botão deveria ter. No meu post sobre workflow de design system com o Claude Code AI, explico como integrou o ProMax ao pipeline inteiro.

Skill 4: Playwright — O Fechador do Ciclo de Testes

É aqui que “engenheiro de IA” deixa de ser apenas um termo de marketing.

Com a integração do Playwright, o Claude Code pode de fato abrir um navegador, navegar até seu aplicativo, clicar em botões, preencher formulários, tirar capturas de tela, ler o DOM e verificar se o que acabou de ser construído realmente funciona. Existem duas variantes em circulação: o Microsoft Playwright MCP server (instale com claude mcp add playwright npx @playwright/mcp@latest) e skills comunitárias baseadas em CLI como lackeyjb/playwright-skill.

A escolha entre CLI e MCP importa mais do que se imagina. O MCP mantém o estado persistente do navegador — ótimo para testes exploratórios, testes autossutentáveis e loops longos e autônomos. Skills baseadas em CLI são mais eficientes em termos de tokens — invocam o Playwright por tarefa e não retêm contexto entre execuções. Para o ciclo “escrever funcionalidade → verificar em um navegador real → iterar”, que é o que a maioria dos engenheiros de fato utiliza, o CLI geralmente é a melhor escolha. Já para sessões de QA orientadas por agentes, que precisam raciocinar sobre vários estados de página, o MCP se destaca.

A demonstração do engenheiro da BookZ.AI tornou isso concreto. Ele apontou o Claude Code para um app no Replit que não era dele — apenas via URL, sem acesso ao código fonte — e ordenou “encontre bugs.” A skill rodou o que o criador chamou de 16 fases de teste. Capturou 81 screenshots nessas fases. Gerou um relatório de QA com defeitos específicos e reproduzíveis: validação de formulário quebrada em um campo específico, modal que prendia o foco incorretamente, botão cujo alvo do clique era 4 px menor que seus limites visuais. (Todos esses números são do walkthrough do criador — rodei um teste menor no meu próprio app e a skill encontrou três problemas reais que eu não havia identificado, mas não vou alegar números no estilo BookZ no meu ambiente.)

Aí entram Superpowers e Fixed Ticket: subagentes planejaram as correções, escreveram testes que falhavam e reproduziam cada defeito, criaram os fixes, verificaram, commitam e implantaram.

Esse é o ciclo completo. Uma única instrução — “encontre bugs e corrija-os” — e as skills se revezaram em papeis que normalmente demandariam três pessoas diferentes.

Quando uso: sempre que uma funcionalidade tem interface gráfica. Hoje também ligo esse fluxo ao CI — uma passagem de smoke tests com Playwright é um critério obrigatório de deploy para qualquer coisa que toque o app de frontend.

Skill 5: Telegram — Controle Remoto

A habilidade que eu tinha certeza de que nunca usaria. Três semanas depois, uso diariamente.

A configuração é simples — inicie o Claude Code com claude --channels plugin:telegram@claude-plugins-official, mande uma DM para o bot, ele responde com um código de pareamento de 6 caracteres, cole o código, pronto. Depois disso, toda mensagem que você enviar para o bot do seu celular será encaminhada para sua sessão local do Claude Code, processada contra seus arquivos reais, e respondida para você no Telegram. O trabalho roda na sua máquina. O controle fica no seu bolso.

Três casos reais de uso que justificaram a funcionalidade:

1. Iniciar tarefas longas longe da mesa. "Execute toda a suíte de testes e me avise se algo quebrar", enviada de um café. Recebo uma notificação 20 minutos depois com o resumo.
2. Reset de sessão e troca de contexto. Você pode resetar a sessão do Claude Code via Telegram, ou alternar qual contexto de projeto está ativo. Útil quando percebo, no jantar, que abri o Claude no repositório errado.
3. Descarregar ideias cognitivamente. Tenho uma ideia. Em vez de anotá-la em um app de notas e esquecer, envio para o bot. Claude registra no cofre Obsidian do projeto (ver próxima habilidade), etiquetado e linkado, e estará lá amanhã.

O modelo de segurança é importante aqui. Apenas usuários do Telegram pareados podem enviar mensagens. É preciso passar explicitamente --channels ao iniciar — não existe modo ambiente “sempre ouvindo”, o que seria um pesadelo. Mensagens não autorizadas são simplesmente descartadas.

Quando uso: toda vez que saio de casa com um job de longa duração rodando. E, cada vez mais, conforme essa habilidade de descarregar ideias se desenvolve, sempre que surge uma ideia que não quero perder.

Habilidade 6: Obsidian — RAG Leve Sem o RAG

Esta foi a que mudou minha forma de pensar sobre memória de projetos.

A habilidade do Obsidian veio de kepano — o CEO do Obsidian. Você coloca ela em uma pasta do seu vault e o Claude Code passa a conseguir ler, escrever, etiquetar e conectar notas markdown em toda a sua base de conhecimento. Nada de banco vetorial. Nada de pipeline de embeddings. Nada de infraestrutura chunk-and-retrieve. Apenas arquivos .md simples, com wikilinks.

O insight de design é o mesmo que Andrej Karpathy vem repetindo publicamente: pipelines tradicionais de RAG são excessivos para gestão pessoal de conhecimento. O problema que o RAG resolve — "encontrar os três parágrafos mais relevantes em 10.000 documentos para essa consulta" — não é o problema real da maioria dos engenheiros. O que a maioria deles tem são 200 notas de reunião, 40 resumos de projeto e 15 registros de decisão de arquitetura, e querem ligar essas notas entre si e permitir que um agente navegue esse grafo.

A habilidade do Obsidian transforma o Claude Code em um agente capaz de fazer essa navegação. Você pergunta: "o que decidimos sobre o refactor de autenticação?" Ele percorre seu vault — lê o ADR, segue o wikilink até a nota da reunião, segue o wikilink até o ticket, segue o wikilink até o commit — e retorna um resumo citando as notas específicas. Quando aprende algo novo, escreve uma nova nota e a conecta ao grafo. O grafo cresce junto com o seu projeto.

A diferença de custo é a parte sem glamour, mas real. Um pipeline de embeddings apropriado, numa base de conhecimento de porte médio, gera custos computacionais contínuos. Um vault markdown não gera custo algum de computação e pode ser versionado com git. A comparação publicada pelo Karpathy estimou a recuperação de qualidade equivalente a cerca de 95% mais barata do que um setup RAG convencional. Para um founder solo ou uma equipe pequena, isso não é um detalhe — é a diferença entre "eu tenho uma base de conhecimento" e "eu não tenho".

Estou rodando isso há cerca de seis semanas nos meus próprios projetos. Pra mim já substituiu o Notion. Minha explicação detalhada de Obsidian RAG ao estilo Karpathy aprofunda a mecânica, se você quiser um passo a passo.

Quando utilizo: sempre ligado. Não é uma habilidade de "recorrer quando preciso" — ela é infraestrutura ambiente. Todo projeto que toco agora tem um diretório /vault e a skill fica ativa por padrão.

Skill 7: O Pacote de Habilidades de Marketing — 43 Habilidades que Quase Ignorei

Achei que seria o ponto mais fraco da stack. É o mais forte.

O pacote reúne cerca de 43 habilidades do Claude Code cobrindo toda a superfície do marketing para SaaS: pesquisa de SEO, planejamento de palavras-chave, otimização on-page, copy para landing pages, experimentos de CRO, sequências de e-mails de nutrição, estratégia de conteúdo, analytics (integração com GA4, detalhamento de receita por canal), monitoramento de funil e relatórios de performance. O plugin próprio da Anthropic para marketing oferece os comandos slash /performance-report, /seo-audit e /email-sequence; o pacote comunitário coreyhaines31/marketingskills amplia ainda mais o alcance.

O engenheiro da BookZ.AI afirma que esse pacote de habilidades levou seu produto de 0 a 1.000 usuários. Não posso verificar de forma independente esse número de usuários — é um número interno dele, e estou apenas relatando a alegação, não um benchmark. O que posso comprovar é a direção do que o pacote faz de fato: ele realiza auditorias reais, gera melhorias concretas on-page e integra com o GA4 para fechar o ciclo de atribuição. Os scores do Lighthouse do site dele — SEO 100, Melhores Práticas 100, Acessibilidade 100, Performance 97 — são os números que um técnico de marketing competente produz com duas semanas de trabalho focado. O pacote comprime esse processo em poucas horas.

Aqui está a tabela de resultados relatada por ele:

A parte que não esperava: as habilidades se compõem com engenharia. Você pode rodar o /seo-audit diretamente no seu código, e ele vai propor alterações específicas em HTML/meta que as habilidades de engenharia podem implementar via o fluxo TDD do Superpowers — primeiro os testes, depois o ajuste, então o redeploy e, em seguida, a nova auditoria. O ciclo se fecha. Marketing não é um workflow à parte grudado na engenharia. É o mesmo workflow, habilidades diferentes.

Se você é um fundador solo tocando um SaaS sem alguém dedicado ao marketing, este pacote provavelmente entrega mais valor por dólar do que qualquer outra coisa que você tenha instalado. Escrevi um artigo detalhado sobre como montar um time de marketing com o Claude Code, que parte exatamente dessa stack.

Quando eu uso: modo marketing, uma vez por semana, nas manhãs de sexta-feira. O skill pack roda as auditorias, agenda os experimentos de CRO, rascunha os e-mails da semana. Eu reviso, aprovo e ele executa.

Habilidade 8: Fixed Ticket — O Pipeline de Correção de Bugs

Guarde o melhor para o final. Esta é a habilidade que me fez repensar como encaro a alocação de tarefas para engenheiros juniores.

O Fixed Ticket recebe uma URL de ticket do Jira como entrada. Ele retorna uma correção implantada e o encaminhamento para QA. Todas as etapas intermediárias são automatizadas, com apenas um ponto de verificação humano na fase de aprovação.

Aqui está o fluxo de trabalho em sete etapas, direto do walkthrough do criador:

A alegação do criador é que essa habilidade substitui cerca de 90% do trabalho de correção de bugs feito por engenheiros juniores. Quero ser cauteloso com esse número porque é a observação dele sobre sua própria equipe — o resultado pode variar conforme a complexidade do codebase, cobertura de testes e qualidade dos tickets no Jira. Um ticket ruim (“app quebrou, conserte”) inviabiliza a habilidade já na Etapa 1.

O que posso confirmar após testar no meu próprio backlog: para tickets com passo de reprodução claro e log do Sentry anexo, a habilidade resolveu tudo de ponta a ponta sem que eu precisasse escrever uma linha de código. Para tickets vagos ou arquitetonicamente ambíguos, o processo travou na Etapa 3 (diagnóstico) e pediu esclarecimentos — exatamente como deveria ser. Não criou uma correção inventada. Não entregou nada errado. Perguntou.

O checkpoint de aprovação é o recurso mais importante. Todo plano de correção chega até você antes que qualquer código seja escrito. Você vê a hipótese, a mudança proposta, o teste que será adicionado e o alvo do deploy. Você aprova, ou redireciona. Esse único ponto de verificação é a diferença entre um “pipeline automatizado de bugs” e um “gerador automatizado de desastres”.

Quando eu uso: na triagem de segunda-feira do backlog do Jira. Aprovo em lote os planos de correção para tickets claros, redireciono os ambíguos e, até quarta-feira, o backlog está visivelmente menor sem que eu tenha escrito código para a maior parte dele.

Como as Oito Habilidades se Combinam

Individualmente, cada habilidade resolve um ponto de falha. Empilhadas, elas produzem algo que funciona como um pequeno time de engenharia:

• Superpowers é a metodologia. Não-negociável para todo o restante.
• Skill Creator é como a metodologia se adapta ao seu workflow, ao invés de um genérico.
• UI/UX ProMax toma as decisões de design para que você não precise.
• Playwright fecha o ciclo entre "código escrito" e "código funcionando".
• Telegram desvincula o agente da mesa, permitindo que tarefas longas rodem em segundo plano.
• Obsidian oferece memória de projeto ao agente sem requerer infraestrutura.
• O pacote de marketing fecha o ciclo entre "produto existe" e "usuários chegam".
• Fixed Ticket é o compressor do ciclo de vida dos bugs — é onde ocorre o maior ganho bruto de tempo.

A observação importante: nenhuma dessas habilidades é de "produtividade geral". Cada uma é cirúrgica. Cada uma corrige algo específico que está quebrado na experiência padrão do Claude Code. O motivo de o stack funcionar como stack é que as correções não se sobrepõem — cada uma domina uma etapa distinta do pipeline de entrega do produto, e elas se compõem em vez de colidir.

Se você estiver montando um stack parecido, a ordem de instalação que recomendo é:

1. Superpowers (semana 1 — não faça mais nada até isso se tornar hábito)
2. Playwright (semana 1 — fecha o loop mais importante)
3. Obsidian (semana 2 — ambiente; configure e esqueça)
4. Fixed Ticket (semana 2 — maior economia de tempo nos backlogs existentes)
5. UI/UX ProMax (semana 3 — quando houver tarefas de UI)
6. O pacote de marketing (semana 3 — quando o produto já existir para divulgação)
7. Telegram (semana 4 — quando os anteriores já rodarem rotineiramente sem supervisão)
8. Skill Creator (contínuo — assim que notar seus próprios padrões, comece a construir)

Onde Este Stack Fica Aquém

Hora de honestidade intelectual, porque todo post do tipo “instalei 8 skills e agora sou um engenheiro 10x” está mentindo.

O stack é específico do ecossistema Claude. Se sua equipe usa múltiplos agentes de codificação ou você quer portabilidade entre provedores, alguns desses (Superpowers, Skill Creator, os plugins específicos do Claude) criam lock-in. As skills que seguem a especificação aberta Agent Skills são mais portáveis.

O custo de setup é real. Não na instalação — a instalação leva minutos. O custo está no tempo para aprender as convenções de cada skill, escrever os arquivos design.md, conectar o Sentry ao seu Jira, construir a estrutura do vault no Obsidian, produzir as baselines de marketing. Considere uma semana de configuração focada antes do stack começar a gerar retorno. Se você está avaliando isso para um sprint de 3 dias, não vale a pena.

O número de 90% de substituição de júnior do Fixed Ticket é do criador, não um fato universal. No meu codebase, começou em algo como 60% e subiu para talvez 75% depois que eu refinei meus processos no Jira e a integração com o Sentry. Ainda é enorme. Mas não são 90%, e eu não confiaria em quem disser que vai ser 90% já no primeiro dia.

As skills de marketing são tão boas quanto sua configuração de analytics. Se o GA4 não estiver corretamente integrado, os relatórios de funil serão inúteis. Se você não possui rastreamento de receita por canal, as recomendações de otimização serão apenas suposições. O skill pack amplifica uma configuração correta — não conserta uma quebrada.

Playwright é instável. Browsers reais são instáveis. Qualquer setup que dependa deles para gates de CI precisa de lógica de retry e captura de screenshot em caso de falha, ou você vai gastar seus ganhos depurando falsos negativos.

O Que Acontece Se Você Não Instalar Nada

Você continua no vibe coding. Entrega features sem testes. Seu backlog do Jira cresce mais rápido do que você consegue fechar tarefas. Sua landing page está com "Melhores Práticas: 78" no Lighthouse e você se promete que vai corrigir isso no próximo trimestre. Seu cofre no Obsidian já tem 14 notas e cresce mais devagar do que o ritmo em que você perde contexto. Você envia mensagens para você mesmo no Telegram que nunca são resolvidas, porque não existe nenhum agente do outro lado.

Essa é a experiência Claude Code da maioria dos engenheiros em 2026. É produtiva. De fato, é mais rápida do que programar sem IA. Mas não é qualitativamente diferente do que um engenheiro experiente faria em 2023 com um bom autocompletar. A diferença qualitativa vem do skills stack — é a passagem de "a IA me ajuda a programar mais rápido" para "a IA entrega produto enquanto eu durmo".

Ainda me lembro do momento que mencionei lá no início — a skill Fixed Ticket entregando um deploy enquanto eu só assistia. O incômodo passou. O sentimento mais duradouro que ficou é este: cada hora que não tenho esse stack rodando é uma hora em que estou fazendo um trabalho que um agente bem configurado poderia fazer por mim. Essa é a conta para a qual eu sempre volto. Se você é um engenheiro solo lançando um produto em 2026, a dúvida não é se deve instalar um skills stack. É qual stack instalar, e quão rápido.

Escolha três skills desta lista ainda esta semana. Superpowers, Playwright e Obsidian é minha recomendação para o kit inicial de maior impacto. Instale-os hoje à noite. Use-os na segunda-feira. Volte aqui em duas semanas e me conte o que você mudaria.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura de tecnologia? Estou à disposição para ajudar.

• Fiverr (soluções e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções corporativas): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io