Akinator AI: Uma Camada de Conhecimento Viva para Agentes de Codificação de IA

Claw Administrator@claw-admin

Publicado em 2026-10-31 · 4 visualizações · 1 leitores conectados

Nesta página

9 min de leitura

Akinator AI é uma camada de conhecimento instalável para agentes de codificação de IA. Ela faz com que o Claude Code, Codex e Cursor leiam a intenção de um repositório antes de alterá-lo, e expanda esse conhecimento na mesma alteração que o código [1]. O projeto descreve a si mesmo com uma única frase de posicionamento: "Uma habilidade. Um comando. Sempre ativa. Seu repo torna-se sua própria wiki" [2]. Seu autor, Ihab Khaled, define-o como uma camada comportamental que captura por que as decisões foram tomadas, e não apenas o que o código faz [3].

Principais conclusões

O Akinator visa três agentes: Claude Code, Codex e Cursor, cada um integrado através de seu mecanismo de extensão nativo [1].
Ele afirma estar sempre ativo: nenhum comando precisa ser chamado durante o trabalho normal após a instalação [2].
Ele rastreia produto, negócio, requisitos, drift, arquitetura, bibliotecas, decisões, histórico, regras, habilidades e memória [1].
O caminho de instalação é um script de shell ou PowerShell de uma única linha, e a desinstalação restaura o repositório byte por byte [2].
O pacote de conhecimento é lido localmente sem daemon, sem rede e sem serviço de indexação [2].

O que o projeto realmente é

A promessa central é uma inversão da divisão de trabalho usual. O código diz como; o Akinator mantém o quê, por que, quem, quando, antes, agora, próximo [1]. Esse enquadramento coloca a ferramenta acima da base de código, e não dentro dela: é uma camada de intenção registrada que o agente consulta antes de editar arquivos.

O README afirma que ele adota as convenções que um repositório já possui e nunca constrói uma wiki paralela [2]. Isso é importante para a adoção, pois significa que a ferramenta deve ser aditiva à documentação existente, em vez de ser uma fonte de verdade concorrente.

Nota:

Nota: O nome é emprestado do jogo de adivinhação Akinator, mas o repositório não é um jogo de adivinhação de personagens. Listagens de diretórios independentes que o descrevem como um jogo de adivinhação são interpretações errôneas do título [4].

Instalação e suporte de plataforma

A instalação é deliberadamente curta. No macOS e Linux, o instalador é obtido e enviado para um shell; no Windows, ele é obtido e invocado através do PowerShell [1]. Após a instalação, o usuário reinicia o agente e faz as solicitações normalmente, pois não há nada explícito a ser chamado [2].

Plataforma	Forma explícita (raramente necessária)	Mecanismo sempre ativo
Claude Code	`/akinator:everything`	Hooks de SessionStart e por prompt [1]
Codex	`$akinator`	Bloco marcado em `AGENTS.md` [1]
Cursor	`/akinator`	Regra sempre aplicada [1]

Várias opções do instalador moldam a pegada. --claude, --codex e --cursor selecionam as plataformas; --repo PATH instala em um único repositório em vez do perfil do usuário; --ref REF fixa uma versão [2]. As atualizações são realizadas executando a mesma linha de instalação, e a desinstalação usa --uninstall (ou -Uninstall no Windows) [1].

Dica:

Dica: Plugins do Cursor requerem seu próprio manifesto de marketplace, que o Akinator não fornece. Portanto, o README recomenda o instalador para o Cursor em vez da rota do plugin [2].

Como funciona a integração sempre ativa

O mecanismo difere por plataforma, mas serve a um único objetivo: o contexto deve chegar sem que o usuário precise pedir. No Claude Code, os hooks são disparados no início da sessão e novamente antes de cada prompt [1]. No Codex, um bloco marcado dentro de AGENTS.md carrega as instruções [1]. No Cursor, uma regra sempre aplicada faz o mesmo trabalho [1].

O Akinator também oferece uma rota de plugin para o Claude Code. O marketplace é adicionado via sua URL HTTPS, atualizado com claude plugin marketplace update akinator e renovado com claude plugin update akinator@akinator [2]. Na extensão do VS Code, o usuário digita /plugins, abre Marketplaces, adiciona a mesma URL e instala o plugin [2].

O instalador é conservador quanto à propriedade dos arquivos. Ele altera apenas arquivos que contenham o banner do Akinator, preserva as quebras de linha existentes e avisa se um AGENTS.override.md irá sobrepor o bloco do Codex [2].

Os domínios de conhecimento que ele mantém

O escopo documentado do Akinator é um conjunto de domínios nomeados, cada um respondendo a uma pergunta diferente sobre o projeto [1].

Product — o que o produto é, faz e deve fazer [1].
Business — lógica de negócios, regras e motivações [1].
Requirements — requisitos atuais e em evolução [1].
Drift — como o produto se afastou da intenção original [1].
Architecture — decisões estruturais, padrões e restrições [1].
Libraries — dependências, versões e por que foram escolhidas [1].
Decisions — decisões técnicas e de produto com a justificativa [1].
History — a linha do tempo de alterações e por que elas aconteceram [1].
Rules — regras de codificação e comportamentais específicas do projeto [1].
Skills — capacidades de agentes reutilizáveis [1].
Memory — contexto persistente entre sessões [1].

A própria descrição do autor adiciona detalhes a essas categorias. Processos repetidos podem ser convertidos em Skills, falhas são lembradas, lições são impostas como Rules, e mudanças são rastreadas entre o antes, o depois e o porquê [3].

Layout do repositório e artefatos gerados

A skill canônica reside em skills/everything/, e o repositório também fornece um diretório de skills akinator [2, 5]. A documentação possui sua própria árvore em docs [6].

Uma regra operacional crucial se aplica ao material gerado. O diretório .agents/, cada router e as páginas da wiki geradas são saídas geradas; eles devem ser regenerados em vez de editados manualmente, com os comandos registrados em CLAUDE.md [2]. O README direciona os leitores para a justificativa de design no ADR 0010 e ADR 0011 [2].

Aviso:

Aviso: Editar manualmente routers gerados ou páginas da wiki quebra o contrato descrito no README. Em vez disso, regenere-os seguindo os comandos em CLAUDE.md [2].

Como ele aborda o drift do produto

O Drift é tratado como um domínio de primeira classe, e não como um efeito colateral. Como o estado anterior, o estado atual, a justificativa da transição e a direção futura são todos registrados [1], um agente pode consultar esse registro antes de agir. Na prática, isso suporta quatro comportamentos:

Evitar reverter decisões que foram deliberadamente alteradas [1].
Entender por que o estado atual difere do plano original [1].
Permanecer consistente com a trajetória do produto [1].
Sinalizar conflitos entre uma nova alteração e a direção estabelecida [1].

Construindo uma "empresa em um repositório"

A proposta de valor prática é que o agente se comporte como se assumisse várias funções ao mesmo tempo. Ele obtém a visão de um engenheiro (arquitetura, escolhas de bibliotecas, regras de codificação), a visão de um gerente de produto (escopo, requisitos, regras de negócio, drift) e a memória da equipe (quem decidiu o quê, quando e por quê) [1]. Quando um usuário solicita "corrigir a tentativa de pagamento falha", o agente pode consultar o contexto do produto, regras de negócio, arquitetura, bibliotecas, decisões, histórico de drift e regras do projeto antes de tocar no código [1].

É nesse sentido que a ferramenta afirma permitir que uma IA faça "vibe code" como uma empresa completa: o modelo não é mais inteligente, mas está melhor instruído. O material de apoio do README inclui uma página de business case ao lado de arquitetura, compatibilidade, regras, contexto, memória, ledger, templates e um contrato de wiki viva [2].

Restrições de design que valem a pena conhecer

Desempenho e privacidade são abordados explicitamente. O README descreve a ferramenta como barata e rápida, e enfatiza que ela lê o pacote de conhecimento em vez da árvore, sem usar daemon, rede ou serviço de indexação [2].

Para equipes preocupadas com lock-in, o licenciamento é direto: MIT, conforme o arquivo LICENSE do repositório [2]. O repositório também expõe branches para aqueles que desejam acompanhar a atividade de desenvolvimento [7].

Onde se situa entre os outros projetos do autor

Ihab Khaled mantém outros trabalhos no mesmo espaço geral. O ClawAI é descrito como um plano de controle de IA local-first que executa modelos abertos na máquina do usuário enquanto se conecta aos principais provedores de LLM, com roteamento, memória e orquestração [8]. Seu changelog documenta a versão 0.2.0, uma mudança de um monólito para nove microsserviços NestJS com mensageria RabbitMQ, Nginx como gateway de API e aproximadamente vinte containers sob Docker Compose [9].

Os dois projetos abordam camadas diferentes. O ClawAI decide qual modelo usar; o Akinator garante que o modelo escolhido entenda o projeto antes de agir [8][1]. Os quadros de projeto e fluxos de trabalho de CI do próprio ClawAI são preocupações de infraestrutura separadas [10][11].

O que não está documentado publicamente

O README obtido cobre instalação, integração de plataforma, domínios e o contrato de arquivos gerados, mas não tudo. Os formatos exatos de arquivo usados para armazenar cada domínio, se a recuperação usa embeddings ou correspondência de palavras-chave, o custo de latência dos hooks, a resolução de conflitos entre entradas de conhecimento, o comportamento de monorepo e a precificação não são descritos no material revisado aqui [1, 2].

Algumas listagens de terceiros adicionam detalhes que o próprio repositório não confirma. Uma descreve um loop de doze estações cobrindo ask, resolve, audit, plan, implement, document, skillify, rule, contextify, memoize, index-and-sync e verify, além de comandos para onboarding, execução do loop e auditoria da camada de conhecimento [13]. Trate isso como uma descrição secundária pendente de confirmação no repositório de origem.

Nota:

Nota: O repositório não é um mecanismo de busca de base de conhecimento geral. Repositórios como AI-Powered-Knowledge-Base-Search cobrem a ingestão de documentos e a recuperação semântica, que é um problema diferente de capturar a intenção do projeto para um agente de codificação [12].

Checklist de adoção

Leia o script de instalação antes de executá-lo, conforme o próprio README recomenda [2].
Execute a linha de instalação do shell ou PowerShell, adicionando flags de plataforma se apenas um agente for usado [1].
Reinicie o agente e faça o prompt normalmente; nenhum comando explícito é necessário [2].
Mantenha os roteadores e páginas da wiki gerados como regenerados, não editados manualmente [2].
Execute novamente a linha de instalação para atualizar e use a flag de desinstalação para restaurar o repositório byte a byte [2].

A aposta mais ampla é simples: um agente que conhece o porquê de uma base de código produz menos edições contraditórias do que um que vê apenas os arquivos. Akinator é uma tentativa de tornar esse conhecimento portátil, versionado e automático [1].