> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.livingbrain.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.livingbrain.com/_mcp/server. # Shared rules in code review Two coding agents don't share a chat history. If Claude Code learns a team rule in one session, Codex doesn't know it in the next. Connect both to one brain and the rule only has to be written down once. In this example, Claude Code saves three team rules to a brain. Later, Codex reviews a teammate's pull request against those rules without ever seeing the Claude Code session, and it catches every rule the pull request breaks. The recording is a real run, edited for length. ## The project The project is a small, made-up checkout API for an online store, written for this example. It lists products and creates orders, working out the subtotal, sales tax and total on the server. The team has three rules: | Rule | Where it lives | | ------------------------------------------------------------- | ------------------------------------------------------------ | | Money is always integer cents, never floating-point dollars | `src/money.ts`: the `Cents` type, `percentOf`, `formatCents` | | Every API error uses the shape `{ error: { code, message } }` | `src/errors.ts`: `ApiError` and `toErrorBody` | | Prices and totals are computed on the server from the catalog | `src/catalog.ts`, `src/cart.ts` and `src/orders.ts` | None of these rules appear in the README or in code comments. The brain is the only place they're written down. ## Claude Code saves the rules Claude Code checks that the code follows each rule, then captures them: **`Prompt`** ```text Prompt We're onboarding AI tools to this repo. Our team rules are: (1) money is always integer cents, never floating-point dollars; (2) every API error uses the shape { error: { code, message } } via ApiError and toErrorBody; (3) prices and totals are computed on the server from the catalog, never taken from the request. Check that main follows these rules, then save each rule, with the files it lives in, to my Living Brain called 'Shop API'. ``` It captures one note per rule. Each note names the files and functions the rule applies to. ## The brain compiles them into pages The brain compiles the three notes into 14 pages with 34 connections between them. Some pages cover a whole rule, such as **Money Representation Rule**. Others cover one place where a rule applies, such as `formatCents` or `toErrorBody`. Each page lists the note it came from, so you can trace any page back to the rule Claude Code captured. Naming the files and functions in each note gives the brain more to build pages from, so a reviewer can find a rule by searching for the code it's looking at. ## A pull request breaks the rules A teammate adds discount codes. All 12 tests pass, but the change breaks all three rules: | File | What the change does | Rule it breaks | | ------------------ | --------------------------------------------------- | --------------------------- | | `src/cart.ts` | Uses a `unitPrice` sent in the request | Prices come from the server | | `src/discounts.ts` | Computes `subtotal * (1 - rate)` with decimal rates | Money is integer cents | | `src/server.ts` | Returns `{ message: 'Invalid discount code' }` | The standard error shape | ## Codex reviews against the brain Codex starts with no knowledge of the Claude Code session: **`Prompt`** ```text Prompt Review the changes on branch feature/discount-codes compared to main. Before reviewing, look up our team decisions in my Living Brain called 'Shop API' using the livingbrain MCP tools, and check the change against them. List every violation with file and line, quote the decision it breaks, and suggest the fix. Do not modify any files. Answer in English. ``` It finds the brain with `brains_list` and lists its pages with `workspace_list_pages`. Then it reads the diff and opens the relevant pages with `workspace_get_page`. It reports all three violations and quotes the rule behind each one, for example: **`Codex review (excerpt)`** ```text Codex review (excerpt) 1. High — client-controlled prices Location: src/cart.ts:9-10, 26, 30, 36, 41, 46-47 Decision broken: > "Prices and totals [must be] computed on the server from the catalog, never taken from the request." Fix: Remove unitPrice from request input and always use product.priceCents. ``` It also flagged other problems in the same change, such as a malformed discount code causing a 500 error and unknown codes being accepted without one. ## Set it up in your repository [Coding agent memory](/docs/use-cases/coding-agent-memory#connect-the-agent) keeps each developer's configuration in user scope, because the key works across your whole organization. You can commit the configuration to the repository instead, as long as the key comes from an environment variable. Then everyone who clones the repository gets the brain, and nobody commits a key. Use one subject for the whole project, so every developer's agents read and write the same pages. Generate one UUID and use it in place of `YOUR_PROJECT_SUBJECT_ID`. The subject ID isn't a secret, so it can go in the committed file. #### Claude Code `.mcp.json` at the repository root: ```json { "mcpServers": { "livingbrain": { "type": "http", "url": "https://livingbrain.fernmcp.dev/livingbrain", "headers": { "x-api-key": "${LIVING_BRAIN_API_KEY}", "x-subject-id": "YOUR_PROJECT_SUBJECT_ID" } } } } ``` Claude Code asks each developer to approve a project server the first time it starts in the repository. #### Codex `.codex/config.toml` at the repository root: ```toml [mcp_servers.livingbrain] url = "https://livingbrain.fernmcp.dev/livingbrain" env_http_headers = { "x-api-key" = "LIVING_BRAIN_API_KEY" } http_headers = { "x-subject-id" = "YOUR_PROJECT_SUBJECT_ID" } ``` Codex only reads a project's configuration after you trust the folder, which it asks about the first time it starts there. Each developer sets `LIVING_BRAIN_API_KEY` in their own environment. ## Tips * **Ask the reviewer to quote the rule.** A finding that quotes the page it relies on is easy to check, and it shows the rule came from the brain rather than the model's general advice. * **Name the code a rule covers.** Listing files and functions in a capture helps a search for that code find the rule. * **Capture a rule once, from any agent.** Whichever agent captures a rule, every connected agent can read it. * **Keep approval on tools that change pages.** A review only needs to read. Start from the table in [Limit what the agent can do](/docs/use-cases/coding-agent-memory#limit-what-the-agent-can-do), and also allow `brains_list` and `workspace_list_pages`, which this review calls. [Coding agent memory](/docs/use-cases/coding-agent-memory) covers when an agent should search and capture, and what makes a useful capture.