Infobank Systems

An infobank is a structured knowledge file (or set of files) that captures everything Claude needs to know about a domain — facts that are always true regardless of the current task. It lives in your project and gets loaded into Claude’s context automatically, so you never have to re-explain the domain from scratch.

The problem it solves

Projects accumulate domain knowledge that isn’t in the code: business rules, architectural decisions, naming conventions, integration quirks, things that are “just how we do it.” This knowledge lives in developers’ heads, in Confluence pages, in Slack threads. Claude doesn’t have access to any of it.

Without an infobank, you either re-explain the context in every prompt (slow, inconsistent) or Claude makes decisions based on what it can infer from the code alone (risky).

What goes in an infobank

Domain invariants — facts that don’t change from task to task:

• “User IDs are always UUIDs, never integers”
• “The events table is append-only — never update or delete rows”
• “All prices are stored in øre (1/100 of a krone), never as floats”

Architectural decisions — why things are built the way they are:

• “We use optimistic locking on the orders table to handle concurrent updates”
• “Auth tokens are stored in HttpOnly cookies, not localStorage”

Integration constraints — what the external systems expect:

• “The payment provider requires idempotency keys on all charge requests”
• “The legacy CRM API returns dates in DD.MM.YYYY format”

Naming and conventions that aren’t obvious from the code.

Structure

An infobank can be a single Markdown file or a directory of topic files. Either works — the key is that it’s always loaded and always up to date.

project/
├── CLAUDE.md               ← references the infobank
└── .claude/
    └── infobank.md         ← or infobank/domain.md, pricing.md, etc.

In your CLAUDE.md, add a reference:

## Domain Knowledge

Read `.claude/infobank.md` before making any decisions about data models,
pricing logic, or external integrations.

Keeping it current

An infobank that’s out of date is worse than no infobank — Claude will confidently act on stale facts. Treat it like documentation: update it whenever a domain invariant changes, and review it at the start of any significant refactor.

A practical habit: when Claude makes a wrong assumption about the domain, add the correct fact to the infobank before continuing. That way the correction sticks.

Infobank vs CLAUDE.md

CLAUDE.md contains instructions for how Claude should work. An infobank contains facts about the domain. They’re complementary — keep them separate so each stays focused.