9. Working with AI
KaKeKiKoKu changes the way you work with your AI. This chapter collects practical tips based on real daily usage experience.
Synchronization and you
KaKeKiKoKu takes care of reminding your AI to synchronize after making changes. Sometimes it may seem insistent, but it's intentional: documentation is the central axis of the system.
Beware of contradictory instructions. If you give the AI an ambiguous instruction that allows it to delay the sync — for example, "do all of this quickly and don't stop" — the AI will delay it, because its primary goal is to fulfill what you ask, and the sync gets in the way. KaKeKiKoKu will do its best to remind it, but if your instructions go against it, yours will prevail. In that case, if the documentation falls behind, it will be your responsibility.
When the AI asks for confirmation
It depends on the AI model you use. With Claude Opus, you can generally say yes to everything. It's only worth reviewing in detail when:
- There are important conceptual changes (architecture decisions, restructurings).
- You suspect the AI is going off track — though with Claude Opus and KaKeKiKoKu this is truly rare, since it always has context.
In practice, constant supervision is not necessary. Trust the process and review when something catches your attention.
How much to supervise documentation
You don't need to review every sidecar the AI modifies. The practical rule:
- Small or routine changes: not worth reviewing. The AI handles it well.
- Significant conceptual changes: review. When the AI documents an important decision, a new architecture, or a change of direction, it's worth confirming it captured the essence correctly.
Note on models: With Claude Opus you can trust quite a lot. With other models, supervision should be greater — some may interpret instructions more freely and leave details undocumented.
How to ask the AI about knowledge
The most practical way is to use the 🤖 buttons in KaKeKiKoKu. When you want to talk to your AI about a specific resource or section:
- Find the resource in the tree or editor.
- Right-click and select "Talk to AI", or click the 🤖 button on the section you're interested in.
- KaKeKiKoKu passes the AI the exact reference: the resource, the section, the context. Without you having to explain anything.
This works for any type of request: "document this decision", "add that we discarded such alternative", "check if this is consistent with the project rules".
When to use chat vs. KaKeKiKoKu buttons
- Use chat when you're in the flow of a conversation, talking about something general or that applies to many things. The natural flow of conversation is most efficient.
- Use KaKeKiKoKu buttons when you want to change topic and talk about something specific. KaKeKiKoKu passes the AI the exact reference, saves you time, and avoids misunderstandings. It's especially useful when you want to point to a specific section without having to type "look at such file, such section".
The key: if the AI already knows what you're talking about, stay in chat. If you need to point it to something new, use KaKeKiKoKu.
When the AI makes a mistake in a sidecar
Generally, AIs like Claude Opus don't often make mistakes in documentation. But when it happens:
- Small silly things: sometimes it takes more time to explain it to the AI than to fix it yourself directly in the KaKeKiKoKu web interface. In those cases, manual touch-up is preferable.
- New or complex ideas: worth reviewing, because sometimes the AI misses a detail. It could be because you expressed yourself ambiguously, because natural language is imprecise, or simply because the AI's prompt compression kicked in and lost some context.
- Expressing ideas in writing: although it seems contradictory, it's often faster to write the AI a quick, rough idea and let it draft it properly in the sidecar. It saves you the writing effort.
When KaKeKiKoKu reports a corrupt context
If KaKeKiKoKu reports that a .wuniq file is corrupt or unreadable, ask your AI to help instead of editing the file by hand. The AI receives KaKeKiKoKu's current recovery guidance and knows how KaKeKiKoKu context files are structured.
The usual safe flow is: run sync, inspect the damaged context, rescue the useful knowledge, create a clean context through KaKeKiKoKu, and sync again. This keeps the project consistent while preserving as much information as possible.
You can ask directly: "KaKeKiKoKu reports a corrupt context for this resource. Recover what can be recovered and leave the project clean."
AI-powered reports
One of KaKeKiKoKu’s most powerful features is generating reports that are passed directly to the AI for analysis. You’ll find them in File > Export Knowledge:
- Executive Summary + AI: generates a high-level project summary (folders + important resources) and passes the file to the AI. You can ask for anything: “make a summary for the CEO”, “identify the risks”, “compare with last sprint’s architecture”. The AI has the project open and the summary as a starting point — the result is a contextualized analysis that no static report can match.
- Pending & Drafts + AI: exports everything marked as pending or draft and passes it to the AI. A project manager can know in seconds what’s missing and ask the AI to prioritize, detect blockers, or propose an action plan.
These reports are snapshots updated to the moment — not static documentation that falls behind. Every time you generate them, they reflect the real state of the project.
About AI environments and models
KaKeKiKoKu works with any client that supports MCP (Model Context Protocol). The Quick Start links to eight annexes: Claude Code, Claude Desktop, ChatGPT Desktop (Codex), Codex CLI, Antigravity 2.0, OpenCode, ZCode, and a generic pattern for other MCP clients. The experience varies depending on the client and the model.
Claude Code (Anthropic) is still the most complete integration today because it is the only client that supports channels: KaKeKiKoKu pushes events to the AI in real time (Automatic mode). This is not a KaKeKiKoKu limitation; it is the current state of AI clients. Every other client works in Precise mode, where KaKeKiKoKu detects changes and you decide when to invoke the AI or paste what it copied to the clipboard.
About models: Claude Opus, in my experience, gives the most consistent results with KaKeKiKoKu — deep reasoning, captures nuances, follows instructions consistently. ChatGPT via Codex is validated after real testing: good collaboration and product creativity. Those two are still what I reach for.
But the ground has moved, and it would be dishonest not to say so: models from Asian labs have improved enormously and are now perfectly capable of working with KaKeKiKoKu. That is a change from what I would have told you a while back. If you already pay for one of them, try it before assuming you need to switch — what matters is whether the model reasons well, uses tools reliably, and respects instructions, not whose logo is on it.
About supervision: some models require more supervision when documenting — they may omit details or interpret instructions more freely. If you have to constantly review everything the AI documents, the tool loses part of its value. A well-written session rules file — the one your client reads at the start of every conversation, covered in each client integration page — reduces this a lot.
Practical advice: pick the client and model you understand best. The architecture supports multiple connections — you can use different AIs on the same project consecutively, each picking up where the previous one left off, thanks to the knowledge that travels with the project.
How KaKeKiKoKu keeps MCP responses safe
Every text response delivered to an AI through MCP has a final 30,000-character safety budget. Normal responses are unchanged. Commands that can naturally produce large collections have their own meaningful fallback, and a final transport guard prevents a future wrapper or unusual path from leaking a silently truncated response.
open still includes the same root context that a separate read would return. If that read fits by itself but the complete opening response does not, KaKeKiKoKu confirms that the project is open, omits the root read as one whole unit, and gives the AI the exact read "Project::." command to run next. It never sends half a root context.
KaKeKiKoKu can keep up to 20 projects open across the shared Web and AI session. MCP open list shows at most 30 project entries in total: every open project first, followed by closed available projects in catalog order. If more exist, it reports how many were omitted and asks the human to use KaKeKiKoKu Web. The Web catalog itself remains complete.
If the final guard ever has to replace an oversized response, it warns that the command may already have completed. The AI should inspect the current state with a narrower read-only command or KaKeKiKoKu Web instead of blindly repeating a write.
About the AI’s built-in memory
Some AI IDEs — like Claude Code — include their own memory system that saves information between sessions in local files on your computer. It sounds useful at first, but when you use KaKeKiKoKu, that memory becomes a problem.
Why? Because two systems are trying to do the same thing, but with very different capabilities:
- The AI’s memory is static. It’s written once and doesn’t update itself. If your project changes — and projects change constantly — the memory falls behind. The AI ends up working with outdated information without realizing it.
- KaKeKiKoKu is dynamic. It syncs with project changes, detects drift, and keeps knowledge up to date. When the AI opens a project with KaKeKiKoKu, it receives the current truth, not a memory from two weeks ago.
Also, the AI’s memory lives on your computer, not in the project. If you switch machines, you lose it. If another AI opens the same project, it can’t see it. KaKeKiKoKu’s knowledge, on the other hand, travels with the project — any AI that opens it accesses the same context.
The advice: tell your AI not to use its memory system for this project, or to delete it if it already created one. An instruction in your session rules file — .claude/rules/wuniq.md for Claude Code, AGENTS.md for Codex and Antigravity, or the equivalent in your IDE — like “Do not use built-in memory, KaKeKiKoKu is the source of truth” is enough. This avoids conflicts between stale information in the memory and current information in KaKeKiKoKu.
Your own notebook: a project the AI can’t see
KaKeKiKoKu is not just a tool for your AI — you are its user too. And anyone who works seriously with an AI accumulates something that isn’t project knowledge yet: half-baked ideas, wild thoughts, doubts, things that cross your mind while the AI is processing and you don’t want to interrupt it. That material deserves a home — but it doesn’t deserve a single token of your AI’s context.
The pattern: create a separate KaKeKiKoKu project just for your notes — MyNotes, Notebook, whatever you like — and uncheck it. From that moment it’s your notebook: it has all of KaKeKiKoKu’s power (entities, sections, internal relations, search from the Web UI, backups), and for the AI it simply doesn’t exist. You can keep it open alongside your other projects and jot things down while the AI works, without breaking the conversation in progress.
Why not just “write it down anywhere”? Raw notes usually meet one of two bad fates: an external notepad, where they disconnect from your workflow and end up lost, or the real project, where they fatten the AI’s context on every session. And there is a third, subtler risk: a creative idea that deliberately contradicts your own project’s doctrine can confuse an AI that reads it as if it were a decision. The unchecked notebook removes all three problems at once.
Git and privacy. If the notebook lives outside your project’s repository, your raw thinking never travels with the code: it will never end up in a public repository by accident. This matters especially if you work for third parties. The pattern also works for teams: a shared notebook can live in its own repository, with its own access control, separate from the code you deliver — .wuniq files are plain text and version naturally under git.
Maturing an idea. When a green note is ready to become real work, tell your AI the path: “open C:\...\MyNotes and read that entity”. That is a one-session exception — the check doesn’t change, and in the next session the notebook is invisible again. The AI reads your notes, you shape them together, and the mature result gets documented where it belongs: in the real project.
Hidden notebook or draft state? They are complementary. The draft state is for green knowledge of the project, which the AI should see but treat with caution. The unchecked notebook is for what is still only yours: what shouldn’t consume anyone’s attention until you decide. Rule of thumb: if you’re not sure the AI should read it on every session, it goes to the notebook.
The first day with KaKeKiKoKu
Let's be honest: the first day with KaKeKiKoKu will be a bittersweet experience.
You'll barely know the tool, and that's normal: you'll struggle a bit with it. If you also give it a large project that has never worked with KaKeKiKoKu, the project will have no context, and you'll feel that KaKeKiKoKu is consuming your AI capacity without giving you immediate benefit. The AI will be documenting instead of helping with your "real" work.
In other words: if you directly give it a large startup project, you'll likely get a bad impression. Between not knowing the tool and what it consumes at the beginning, the cost-benefit ratio seems negative.
But then everything changes.
Over time — days, not weeks — you'll experience an incredible feeling. As if the AI had a deep understanding of your project. It understands you. You talk to it as if it knows your project in detail. You can discuss subtle aspects and it follows. It documents automatically. It catches functional bugs where it didn't before. And the most wonderful thing: the knowledge passes between sessions, passes between different AIs, becomes a permanent part of your project.
To the point that when you get used to KaKeKiKoKu, the difference from working without it is remarkable.
The advice: start with a small or new project. Learn the tool at a manageable scale. Once you understand the flow, apply it to large projects. The initial investment pays off handsomely.