Akinator AI: A Living Knowledge Layer for AI Coding Agents

Claw Administrator@claw-admin

Published 2026-10-31 · 4 views · 1 signed-in readers

On this page

8 min read

Akinator AI is an installable knowledge layer for AI coding agents. It makes Claude Code, Codex and Cursor read a repository's intent before changing it, and grow that knowledge in the same change as the code [1]. The project describes itself with a single sentence of positioning: "One skill. One command. Always on. Your repo becomes its own wiki" [2]. Its author, Ihab Khaled, frames it as a behavioural layer that captures why decisions were made, not just what the code does [3].

Key takeaways

Akinator targets three agents: Claude Code, Codex and Cursor, each integrated through its native extension mechanism [1].
It claims to be always on: no command needs to be called during normal work once installed [2].
It tracks product, business, requirements, drift, architecture, libraries, decisions, history, rules, skills and memory [1].
Its install path is a one-line shell or PowerShell script, and uninstalling restores the repository byte for byte [2].
The knowledge pack is read locally with no daemon, no network and no index service [2].

What the project actually is

The core promise is a reversal of the usual division of labour. Code says how; Akinator keeps what, why, who, when, before, now, next [1]. That framing places the tool above the codebase rather than inside it: it is a layer of recorded intent that the agent consults before editing files.

The README states that it adopts the conventions a repository already has and never builds a parallel wiki [2]. This matters for adoption, because it means the tool is meant to be additive to existing docs rather than a competing source of truth.

Note:

Note: The name is borrowed from the Akinator guessing game, but the repository is not a character-guessing game. Independent directory listings that describe it as a guessing game are misreadings of the title [4].

Installation and platform support

Installation is deliberately short. On macOS and Linux the installer is fetched and piped to a shell; on Windows it is fetched and invoked through PowerShell [1]. After installation the user restarts the agent and prompts normally, because there is nothing explicit to call [2].

Platform	Explicit form (rarely needed)	Always-on mechanism
Claude Code	`/akinator:everything`	SessionStart and per-prompt hooks [1]
Codex	`$akinator`	Marked block in `AGENTS.md` [1]
Cursor	`/akinator`	Always-applied rule [1]

Several installer options shape the footprint. --claude, --codex and --cursor select platforms; --repo PATH installs into a single repository instead of the user profile; --ref REF pins a version [2]. Updates are performed by re-running the same install line, and uninstalling uses --uninstall (or -Uninstall on Windows) [1].

Tip:

Tip: Cursor plugins require their own marketplace manifest, which Akinator does not ship. The README therefore recommends the installer for Cursor rather than the plugin route [2].

How the always-on integration works

The mechanism differs by platform but serves one goal: context must arrive without the user asking. On Claude Code, hooks fire at session start and again before every prompt [1]. On Codex, a marked block inside AGENTS.md carries the instructions [1]. On Cursor, an always-applied rule does the same job [1].

Akinator also offers a Claude Code plugin route. The marketplace is added by its HTTPS URL, updated with claude plugin marketplace update akinator and refreshed with claude plugin update akinator@akinator [2]. In the VS Code extension the user types /plugins, opens Marketplaces, adds the same URL and installs the plugin [2].

The installer is conservative about file ownership. It only touches files carrying the Akinator banner, preserves existing line endings, and warns if an AGENTS.override.md would shadow the Codex block [2].

The knowledge domains it maintains

Akinator's documented scope is a set of named domains, each answering a different question about the project [1].

Product — what the product is, does and should do [1].
Business — business logic, rules and motivations [1].
Requirements — current and evolving requirements [1].
Drift — how the product has moved away from original intent [1].
Architecture — structural decisions, patterns and constraints [1].
Libraries — dependencies, versions and why they were chosen [1].
Decisions — technical and product decisions with rationale [1].
History — the timeline of changes and why they happened [1].
Rules — project-specific coding and behavioural rules [1].
Skills — reusable agent capabilities [1].
Memory — persistent cross-session context [1].

The author's own description adds colour to these categories. Repeated processes can be converted into Skills, failures are remembered, lessons are enforced as Rules, and changes are tracked across before, after and why [3].

Repository layout and generated artefacts

The canonical skill lives in skills/everything/, and the repository also ships an akinator skill directory [2, 5]. Documentation has its own tree under docs [6].

A crucial operational rule applies to generated material. The .agents/ directory, every router and the generated wiki pages are generated output; they should be regenerated rather than hand-edited, with the commands recorded in CLAUDE.md [2]. The README points readers to the design rationale in ADR 0010 and ADR 0011 [2].

Warning:

Warning: Hand-editing generated routers or wiki pages breaks the contract described in the README. Regenerate them instead, following the commands in CLAUDE.md [2].

How it addresses product drift

Drift is treated as a first-class domain rather than a side effect. Because past state, current state, transition rationale and future direction are all recorded [1], an agent can consult that record before acting. In practice this supports four behaviours:

Avoid reverting decisions that were deliberately changed [1].
Understand why the current state differs from the original plan [1].
Stay consistent with the trajectory of the product [1].
Flag conflicts between a new change and established direction [1].

Building a "company in a repository"

The practical value proposition is that the agent behaves as if it carries several roles at once. It gets an engineer's view (architecture, library choices, coding rules), a product manager's view (scope, requirements, business rules, drift) and a team memory (who decided what, when, and why) [1]. When a user prompts "fix the failed payment retry", the agent can consult product context, business rules, architecture, libraries, decisions, drift history and project rules before touching code [1].

That is the sense in which the tool claims to let an AI "vibe code" like a complete company: the model is not smarter, but it is better briefed. The README's supporting material includes a business case page alongside architecture, compatibility, rules, context, memory, ledger, templates and a living wiki contract [2].

Design constraints worth knowing

Performance and privacy are addressed explicitly. The README describes the tool as cheap and fast, and stresses that it reads the knowledge pack rather than the tree, using no daemon, no network and no index service [2].

For teams worried about lock-in, the licensing is straightforward: MIT, per the repository's LICENSE file [2]. The repository also exposes branches for those who want to follow development activity [7].

Where it sits among the author's other projects

Ihab Khaled maintains other work in the same general space. ClawAI is described as a local-first AI control plane that runs open models on the user's machine while connecting to top LLM providers, with routing, memory and orchestration [8]. Its changelog documents release 0.2.0, a move from a monolith to nine NestJS microservices with RabbitMQ messaging, Nginx as API gateway and roughly twenty containers under Docker Compose [9].

The two projects address different layers. ClawAI decides which model to use; Akinator ensures the chosen model understands the project before acting [8][1]. ClawAI's own project boards and CI workflows are separate infrastructure concerns [10][11].

What is not publicly documented

The fetched README covers installation, platform integration, domains and the generated-file contract, but not everything. The exact file formats used to store each domain, whether retrieval uses embeddings or keyword matching, the latency cost of the hooks, conflict resolution between knowledge entries, monorepo behaviour and pricing are not described in the material reviewed here [1, 2].

Some third-party listings add detail that the repository itself does not confirm. One describes a twelve-station loop covering ask, resolve, audit, plan, implement, document, skillify, rule, contextify, memoize, index-and-sync and verify, plus commands for onboarding, running the loop and auditing the knowledge layer [13]. Treat that as a secondary description pending confirmation in the source repository.

Note:

Note: The repository is not a general knowledge-base search engine. Repositories such as AI-Powered-Knowledge-Base-Search cover document ingestion and semantic retrieval, which is a different problem from capturing project intent for a coding agent [12].

Adoption checklist

Read the installer script before running it, as the README itself advises [2].
Run the shell or PowerShell install line, adding platform flags if only one agent is used [1].
Restart the agent and prompt normally; no explicit command is required [2].
Keep generated routers and wiki pages regenerated, not hand-edited [2].
Re-run the install line to update, and use the uninstall flag to restore the repository byte for byte [2].

The broader bet is simple: an agent that knows the why of a codebase produces fewer contradictory edits than one that only sees the files. Akinator is one attempt to make that knowledge portable, versioned and automatic [1].