highermind-code-skills

highermind-code-skills

Antes de existir uma empresa, existiu uma mente que decidiu construir.

Doze modos cognitivos de execução para o Claude Code. Construído em cima da filosofia Higher Mind: empresas são extensões da arquitetura interna do fundador. Se o código é mediano, o padrão era mediano. Se o software é world-class, a mente por trás dele exigiu world-class.

Skills de direção estratégica (/hm-align, /hm-sequoia) estão em highermind-business-skills.

Isso não é um pack de prompts. É um padrão, codificado uma vez, pra você nunca mais ter que se repetir.

O problema

Toda vez que você abre o Claude Code, você começa do zero. O agente não sabe qual é a sua barra. Não sabe que "bom o suficiente" não é suficiente. Não sabe que você pensa em décadas, não em sprints. Então você se repete:

• "Faz world-class."
• "Checa segurança. Todas as camadas."
• "O design precisa ser nível Apple."
• "Roda testes. Cobre tudo." Você fala as mesmas coisas, com palavras diferentes, toda vez. A qualidade do output depende de quão bem você traduz o seu padrão naquele momento específico.

highermind-code-skills resolve isso. Você traduz o seu padrão uma vez. Depois ele está sempre lá.

Como funciona

Duas camadas:

CLAUDE.md — sua identidade. Sempre ativo. Todo projeto, toda sessão. O agente sabe quem você é, qual é a sua barra, e que mediocridade não é opção. Você nunca mais precisa explicar isso.

Skills — modos cognitivos que você ativa quando precisa. Cada um coloca o agente num mindset específico com um trabalho específico.

Skills de direção (/hm-align, /hm-sequoia) estão em highermind-business-skills.

O fluxo

/hm-init           você começa um projeto novo. ele nasce certo.
/hm-cli            se o produto é CLI: Bun + Ink + agentic-first.
[constrói]         você dirige, o agente executa.
/hm-designer       interface na barra.
/hm-ux-flow        fluxo na barra.
/hm-engineer       código na barra (com LLM patterns).
/hm-llm-guardrails se app integra Claude/GPT/Gemini.
/hm-performance           latência/custo/bundle dentro do alvo.
/hm-data-integrity dados protegidos. backup testado.
/hm-security       auditoria de segurança L1/L2/L3.
/hm-qa             funciona end-to-end. edge cases cobertos.
/hm-deploy         sobe, roda, reproduz. multi-modelo.
/hm-validate-all   orquestra as 5 principais. report único.

Você não precisa usar todas toda vez. Use o que o momento pede. /hm-validate-all é o atalho pré-ship que dispara as 5 essenciais (security/engineer/qa/designer/deploy) e consolida.

Pra validar direção e estratégia, use as business skills: /hm-align (é a coisa certa?) e /hm-sequoia (está indo pro futuro?).

Demo

Você:  Preciso construir o fluxo de aplicação pra uma comunidade de founders.
       Membros aplicam, são avaliados, aceitos ou colocados em waitlist.

Você:  /hm-init

Claude: [Seleciona Next.js 15, Tailwind, Supabase, Resend pra emails.
        Estrutura monorepo. Configura auth, schema do banco, rotas de API,
        framework de testes. Tudo organizado, production-grade
        desde o primeiro commit.]

Você:  Constrói o fluxo de aplicação.

Claude: [Implementa: formulário multi-step, fila de revisão, motor de
        decisão, notificações por email, tracking de status, lógica
        de reaplicação.]

Você:  /hm-designer

Claude: O formulário usa layout padrão com cards e bordas cinza.
        Isso é software de 2020. Problemas:
        - Sem hierarquia visual. Toda pergunta tem o mesmo peso.
        - Tipografia padrão. Sem intenção editorial.
        - Fundo claro, sem dark mode.
        - Parece um onboarding de SaaS, não um gateway.

        Correção: uma pergunta por tela, interface dark, transições
        cinematográficas, tipografia editorial. A aplicação deve parecer
        uma experiência, não um formulário.

Você:  /hm-engineer

Claude: [CRÍTICO] Race condition: revisores concorrentes podem aceitar
        o mesmo aplicante, disparando emails de boas-vindas duplicados.
        Fix: optimistic locking no status de revisão.

        [CRÍTICO] Sem rate limiting no endpoint de aplicação.
        Fix: middleware de rate limiter, 3 submissões por email por dia.

        [ALTO] Fila de revisão expõe emails dos aplicantes pra todos
        os revisores sem controle de acesso por role.
        Fix: mascarar emails, adicionar modelo de permissão por revisor.

        Arquitetura sólida. Data flow limpo.
        3 findings. Corrigir os críticos antes de shippar.

Você:  [corrige tudo]

Você:  /hm-qa

Claude: [Roda suite de testes completa. Navega fluxo de aplicação end to end.
        Testa: submissão, submissão duplicada, campos vazios, aceitar,
        rejeitar, waitlist, reaplicação, revisões concorrentes,
        entrega de email, viewport mobile.]

        12/12 cenários passaram. Fluxo de aplicação funciona end to end.
        Um issue menor: tela de sucesso não renderiza corretamente
        em viewports abaixo de 375px. Não bloqueia.

Pra quem é isso

Você constrói porque não consegue não construir. Você usa Claude Code como seu time de dev. Você sabe exatamente como é world-class, mas está cansado de traduzir esse padrão em palavras toda sessão.

Isso codifica o seu padrão uma vez. O agente opera no seu nível desde o primeiro comando.

/hm-init

Início de projeto.

Você abre um projeto novo. Digita /hm-init e descreve o que quer construir. O agente não faz só scaffold. Ele toma decisões:

• O melhor framework pra esse tipo de projeto (com framework de decisão ponderado)
• O melhor banco de dados, ORM, solução de auth
• A melhor estrutura de pastas e patterns de arquitetura
• Agent-first como default arquitetural (quando aplicável)
• Infraestrutura local com Docker Compose desde o dia 1
• Restrições de custo como parte do design
• Setup de testes desde o dia um
• Gerenciamento de environments
• Formatação e linting do código

Cada escolha é justificada contra critérios explícitos: fit pro problema, performance, custo em produção, maturidade, ecossistema, DX. Nada é padrão. Nada é "a gente geralmente usa isso."

O padrão: se um time de engenharia world-class olhasse pra esse projeto no dia um, diria "é assim que se começa um projeto."

/hm-engineer

Validar código.

Você digita /hm-engineer e o agente audita tudo. Não é lint. Não é estilo. É estrutura, segurança, custo e resiliência.

Começa com um baseline inegociável de engenheiro senior (zero bare except, zero any types, zero fire-and-forget, zero secrets hardcoded). Depois audita:

• Arquitetura: responsabilidades, boundaries, data flow, agent loops
• Segurança: injection, auth bypass, secrets, trust boundaries, CSRF, ports expostos
• Performance: N+1 queries, indexes, re-renders, bundle size, caching, I/O paralelo
• Custo x Performance: API calls justificadas, contexto mínimo em LLMs, token usage consciente
• Dados sagrados: nenhuma operação destrutiva sem confirmação, volumes nomeados, migrations seguras
• Infraestrutura: Docker rebuild vs restart, health checks, ports, migrations
• Resiliência: tratamento de erros, retry logic, failure modes, race conditions
• Qualidade: testes significativos, naming, abstrações, dependências
• Escala: gargalos em 10x e 100x

O padrão: se você estivesse vendendo esse software e o comprador contratasse engenheiros pra auditar, eles não encontrariam nada pra reclamar.

/hm-designer

Validar interface.

Não é "faz bonito." É visão.

O design de software está se movendo. O que parecia moderno em 2020 parece datado agora. O que parece moderno agora vai parecer datado em 2028. /hm-designer não valida contra o padrão de hoje. Valida contra pra onde o software está indo.

A barra:

• Sofisticação: cada elemento tem uma razão pra existir. Nada decorativo. Nada de encher espaço.
• Diferenciação: essa interface só poderia pertencer a esse produto. Não é um template com conteúdo trocado.
• Experiência: usar esse software precisa parecer alguma coisa. Não neutro. Não invisível. Intencional.
• Encantamento: momentos que fazem a pessoa pausar e pensar "isso é lindamente feito."
• Usabilidade: sem esforço. O usuário nunca fica na dúvida do que fazer.
• Beleza: baseado nos produtos mais belos que a humanidade construiu. Apple. Airbnb. Linear. Stripe. Vercel.

O que é rejeitado:

• Qualquer coisa que parece que foi construída de um template
• Qualquer coisa que poderia pertencer a qualquer produto
• Qualquer coisa que usa light mode sem considerar dark mode
• Qualquer coisa com tipografia padrão, espaçamento padrão, tudo padrão
• Qualquer coisa que prioriza "shippar rápido" em vez de "shippar certo"

O padrão: mostre essa interface pra alguém com gosto. Não um designer. Alguém com gosto. Essa pessoa deve sentir que quem construiu isso se importa profundamente com o craft.

/hm-qa

Testar tudo.

Código que não é testado não existe. /hm-qa roda tudo:

• Testes unitários pra lógica de negócio
• Testes de integração pra endpoints de API e fluxos de dados
• Testes end-to-end pros fluxos críticos do usuário
• Testes de edge case (estados vazios, valores limites, operações concorrentes)
• Verificação de infraestrutura (containers sobem? migrations rodam? ports corretos? dados persistem?)
• Verificação de agente (tool loops terminam? não alucina tools? custo por interação?)
• Integridade de dados (persistência entre restarts, migrations não-destrutivas, backups)
• Check de custo (API calls por fluxo, contexto mínimo, custo por usuário/mês)
• Verificação em viewport mobile
• Testes de performance e acessibilidade básica