O que é o i-have-adhd

O i-have-adhd é uma skill criada para tornar as respostas de agentes de código mais fáceis de executar. A proposta é simples: colocar a próxima ação em evidência, numerar tarefas e reduzir explicações que desviam do problema original.

O repositório é mantido por ayghri e publicado sob a licença MIT. A página pública do GitHub o descreve como uma skill para impedir que o agente esconda a resposta no meio de uma explicação longa.

A página do projeto não destaca uma data única de lançamento. O que está claro é a dor que ele aborda: conforme agentes de código assumem tarefas maiores, uma resposta tecnicamente correta ainda pode ser ruim se o desenvolvedor não souber qual comando executar primeiro.

Como funciona

O centro do projeto é o arquivo SKILL.md. Ele reúne as regras de comportamento e funciona como a fonte principal do formato esperado. Os arquivos de cada plataforma servem para conectar essa mesma ideia ao ambiente escolhido.

O repositório também mantém adaptadores e metadados para diferentes runtimes. O guia de agentes lista integrações para Claude Code, Códex, Pi, OpenCode, Qwen, Kimi, Gemini e outros ambientes que entendem skills ou plugins.

Quando a skill está ativa, ela atua na camada de instruções da conversa. Ela não troca o modelo de linguagem nem verifica automaticamente se o código sugerido está correto. O ganho está em organizar a resposta para que o dev consiga revisar, executar e retornar o resultado do próximo passo.

Principais recursos

O conjunto principal tem 10 regras de saída. Elas foram pensadas para transformar uma conversa extensa em uma sequência curta de ações verificáveis, sem retirar do agente a capacidade de explicar quando a pessoa pedir detalhes.

  • Ação primeiro: começar pelo comando, caminho ou decisão mais útil.
  • Ordem clara: numerar tarefas e limitar cada passo a uma ação bem definida.
  • Estado visível: informar o progresso e mostrar o que passou a funcionar depois de uma mudança.
  • Erros objetivos: indicar localização, causa e correção sem dramatização.
  • Fechamento concreto: terminar com uma única próxima ação e evitar preâmbulos, recapitulações e encerramentos vagos.

Há também um exemplo de antes e depois no README. A resposta longa é convertida em uma sequência que aponta para src/auth.ts:42, sugere os testes relevantes e pede a primeira linha que falhar. Esse formato reduz a distância entre ler a resposta e começar a trabalhar.

O projeto inclui ainda arquivos de instalação, guias de agentes, diretórios de testes e metadados de plugin. Isso facilita usar a mesma convenção em mais de um assistente sem manter uma cópia manual diferente para cada ferramenta.

Como começar: instalação ou acesso passo a passo

Antes de instalar, confirme que o CLI do agente está disponível e que o ambiente pode acessar o repositório público no GitHub. A instalação adiciona os arquivos do plugin, mas cada plataforma define como a skill será invocada.

No Códex, o fluxo documentado pelo projeto é adicionar o marketplace, instalar o plugin e chamar a skill de forma explícita:

códex plugin marketplace add ayghri/i-have-adhd --ref main; códex plugin add i-have-adhd@i-have-adhd; códex plugin list

Depois, use $i-have-adhd na conversa. No Claude Code, o projeto documenta um fluxo equivalente com o marketplace do Claude:

claude plugin marketplace add ayghri/i-have-adhd; claude plugin install i-have-adhd@i-have-adhd; claude plugin list

O Códex não ativa a skill automaticamente só porque o plugin foi instalado. Essa separação é útil para quem quer manter o modo opcional: invoque a skill em uma tarefa de depuração, revisão ou operação em que respostas curtas sejam mais importantes.

Exemplo prático

Imagine que um agente encontrou uma chamada antiga na autenticação. Uma resposta convencional pode explicar o middleware, a biblioteca e várias dependências antes de dizer qual arquivo deve ser alterado. Para uma tarefa operacional, essa ordem esconde o ponto de partida.

O exemplo do README reorganiza a mesma situação em uma sequência pequena. Ele aponta o arquivo, delimita as linhas e termina com um teste que produz um resultado observável:

npm install jsonwebtoken@latest; abra src/auth.ts; atualize verifyToken nas linhas 42 a 58; execute npm test -- auth.spec.ts; envie a primeira linha que falhar

Em um projeto brasileiro, você pode complementar o pedido com o contexto necessário: versão do runtime, sistema operacional, comando já executado e limite de tempo. A skill organiza a resposta, mas a qualidade do diagnóstico ainda depende das evidências fornecidas.

Comparação com alternativas

O caminho mais simples é escrever uma regra local em um arquivo de instruções do projeto. Isso funciona bem quando a equipe quer um padrão exclusivo, mas exige manutenção manual e não oferece, por si só, adaptadores para vários agentes.

  • Prompt avulso: rápido para testar, porém fácil de esquecer ou repetir com variações.
  • AGENTS.md local: bom para regras específicas do repositório, com escopo direto naquele projeto.
  • Skill nativa: adequada quando o agente já lê arquivos SKILL.md e permite ativação controlada.
  • Plugin: útil quando a plataforma precisa de manifesto, comando, hook ou adaptador próprio.

O diferencial do i-have-adhd é juntar uma fonte canónica de comportamento com arquivos de integração para plataformas distintas. Assim, a equipe pode manter a ideia de resposta acionável sem reescrever todas as regras a cada troca de CLI.

Isso não torna a skill automaticamente melhor em todos os cenários. Para uma aula conceitual, uma investigação complexa ou uma decisão arquitetural, a resposta precisa de espaço para explicar hipóteses e riscos. A escolha depende do tipo de conversa.

Pontos positivos e limitações

O ponto forte é a clareza operacional. Comandos, caminhos, estado atual e próxima ação aparecem cedo, o que ajuda especialmente quando o agente já analisou muitos arquivos e o leitor precisa recuperar o fio da tarefa.

Outra vantagem é a portabilidade. O repositório separa o comportamento central dos adaptadores de runtime e informa que o arquivo canónico deve ser alterado primeiro quando a regra da skill mudar.

⚠️
Atenção

Uma resposta curta não é sinônimo de uma resposta correta. Revise comandos destrutivos, valide versões e peça evidências antes de aplicar mudanças em produção.

Entre as limitações, a skill não substitui testes, revisão humana, documentação do projeto ou conhecimento do domínio. Ela também depende do suporte do runtime escolhido e pode precisar de invocação explícita, como acontece no fluxo documentado para Códex.

Casos de uso reais

O valor aparece em tarefas em que o próximo passo é mais importante do que uma introdução longa. A seguir estão cenários concretos para devs que já usam agentes no terminal, no editor ou em rotinas de revisão.

  • Depuração: pedir o arquivo, a linha, o comando de reprodução e o teste seguinte.
  • Pull request: separar achados por prioridade e terminar com uma ação de correção verificável.
  • Aprendizado: avançar em passos pequenos e pedir uma explicação adicional apenas quando necessário.
  • Operações: registrar estado, impacto, comando seguro e critério de validação durante um incidente.

Para quem trabalha sozinho, isso reduz o custo de voltar a uma tarefa interrompida. O estado explícito ajuda a distinguir o que foi confirmado do que ainda é hipótese.

Em uma equipe, o formato também pode funcionar como convenção de revisão. Cada pessoa recebe respostas com limites semelhantes, sem impedir que o projeto mantenha suas próprias regras de segurança, testes e deploy.

Dicas e boas práticas

Comece usando a skill em tarefas reversíveis, como explicar um erro de build, localizar um teste ou organizar um checklist. Depois de entender o formato, leve a convenção para operações com mais impacto.

💡
Dica

Peça sempre o caminho do arquivo, a ação seguinte e o comando de validação. Esses três elementos evitam respostas genéricas.

🚀
Pro tip

Combine a skill com as regras do seu repositório. A primeira organiza a conversa; as instruções locais continuam definindo arquitetura, testes e limites de segurança.

⚠️
Atenção

Se a tarefa exigir contexto, peça ao agente para explicar a hipótese depois de registrar a ação imediata. Brevidade não deve apagar incertezas importantes.

🔴
Cuidado

Não transforme a regra de ação primeiro em autorização automática. Antes de apagar dados, publicar código ou mudar infraestrutura, confirme escopo e faça uma validação segura.

O próprio projeto recomenda manter listas curtas, dar estimativas em unidades concretas e mostrar vitórias visíveis. São ajustes pequenos, mas melhoram bastante a leitura de uma sessão longa.

Vale a pena?

O i-have-adhd vale testar se você usa agentes de código com frequência e sente que as respostas escondem o comando, o arquivo ou a decisão mais importante. A licença MIT e o repositório público deixam o experimento acessível.

Ele não é uma solução para todos os problemas de engenharia. Quem precisa de uma explicação extensa, de uma análise de produto ou de uma revisão de segurança deve continuar pedindo contexto, evidências e justificativas.

O próximo passo é abrir o repositório oficial, ler o guia de instalação da sua ferramenta e ativar a skill em uma tarefa pequena. Compare o tempo até a primeira ação com o seu fluxo habitual e ajuste as regras locais conforme a experiência.