AGENTS

Give coding agents the context that does not belong in the code.

A repository can explain the system around the repository.

The problem

Coding agents are excellent at reading source code, but important context often lives elsewhere: architectural intent, product constraints, conventions, migration history and decisions.

What goes in the repository

Architecture
Conventions
ADRs
Product context
Domain terminology
Integration constraints
Migration plans
Known pitfalls

engineering/
├── index.md
├── architecture.md
├── conventions.md
├── decisions/
├── integrations/
└── migrations/

Why an open repository helps

The codebase and knowledge repository solve different parts of the context problem.

How Okide helps

Okide is where that surrounding context is maintained, so a coding agent can be pointed at files instead of a prompt that restates the architecture.

Humans and agents, same files

A coding agent can consult durable context before proposing changes and leave useful new context behind for later work.

OPEN BY DEFAULT

Keep the repository. Change the tools around it.

Let the code explain the implementation. Let the knowledge repository explain the intent. Okide helps you work with the repository without turning it into an Okide-only format.

Learn about Open Knowledge Format → Download Okide — free

Related use cases

ROLES

Engineering knowledge

Preserve architecture, decisions and technical context.

engineering/architecture/

Explore →

AGENTS

Agent handoffs

Let the next agent understand what the last one learned.

context/handoff.md

Explore →

TEAMS

Project knowledge

Give every contributor the same context.

projects/atlas/index.md

Explore →