CSBP (Codex Shared Best Practice) is a lightweight three-file protocol kit for keeping recurring Codex best practices explicit, reviewed, and separate from automatic memory orDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/CSBP-Codex-Shared-Best-Practice/llms.txt
Use this file to discover all available pages before exploring further.
AGENTS.md. It is not a memory system that writes itself. It is a review gate — a controlled layer that sits between chat history and your host contract, ensuring that only practices strong enough to reuse, and deliberate enough to approve, ever reach runtime.
The problem CSBP solves
Long-lived Codex setups tend to fail in two opposite directions. Useful guidance either stays buried in chat history where it cannot be consistently applied, or it gets promoted too quickly intoAGENTS.md before it has proven recurring value. A third failure mode is often worse: automatic persistence. Session residue, operator preferences, one-off fixes, and rough observations can start shaping future behavior without enough review.
CSBP does the opposite. Every practice that enters the runtime layer has been evaluated against explicit admission criteria, normalized into a stable block shape, proposed to the operator, and approved. Nothing is written silently. Nothing is applied without prior promotion.
CSBP is for recurring operational practices that are strong enough to reuse across sessions, but not strong enough to become part of your host contract. It is not a replacement for
AGENTS.md and it does not override higher-authority instructions.The controlled middle layer
CSBP occupies a specific position in the authority stack. Every CSBP practice is lower-authority than everything above it:AGENTS.md, or local project guidance, the conflicting CSBP item is not applied. CSBP never creates new policy authority for itself. Runtime practices do not define policy, scope, or authority — they only provide operational guidance when their stated condition matches the current work.
The three files
CSBP is intentionally small. The entire system is three files, each with a distinct and non-overlapping job.| File | Role | When it is read |
|---|---|---|
CSBP-entry-point.txt | Bootstrap and routing layer. Defines what CSBP is, authority order, usage modes, read order, and write restrictions. | First, every session. |
shared-best-practice.txt | Runtime layer. Stores promoted practices only. Active practices may guide work when their applies_when condition matches. | After the entry point. |
shared-best-practice-compiler.txt | Formation layer. Evaluates, normalizes, promotes, revises, deprecates, removes, or rejects candidate practices. | Only when practice formation or maintenance work is requested. |
CSBP-entry-point.txt and shared-best-practice-compiler.txt are fixed system-definition layers. Do not modify, rewrite, or extend them. The only file that changes during normal operation is shared-best-practice.txt, and only after operator approval.What CSBP is — and is not
CSBP is built for patterns like these:- The same mistake keeps appearing across sessions
- Codex repeatedly misses the same verification step
- A useful working default keeps being rediscovered
- An environment-level constraint should be available without rewriting
AGENTS.md - A recurring operational correction is worth persisting across sessions
AGENTS.md or local instructions. This filter is part of the system. CSBP is useful because it says no.
CSBP has no background writer. It does not capture session content automatically, create rules silently, or promote anything without explicit operator approval. Codex may propose. The compiler may evaluate. The operator decides. The runtime file changes only after approval.
License
CSBP is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0).
Quickstart
Install CSBP in your Codex setup in a few steps and verify it is active.
The Three-File System
Understand the roles of each file and why the layer separation matters.