TheScheme: a Codex schema-file system built from Markdown, YAML, XML and LLM-attention research, with a routed TypeScript ruleset
I’ve been working on a project called TheScheme for managing how Codex follows rules inside a codebase.
TheScheme is the template behind everything. It defines how rules are written, how Codex routes between them, and how to stop a large set of instructions from turning into one huge prompt that gets partially ignored.
Instead of putting every instruction into "AGENTS.md", it uses a main router and smaller rule files. Codex starts with the router, works out what the task touches, and only loads the files it needs.
The first full ruleset I built with it is Pragmatic TypeScript. I’ve been using it with Codex on actual projects.
The basic TypeScript approach is:
"Type Strategy → Functional Core → Procedural Shell → Smallest Honest Boundary"
In practice, that means making the domain meaning clear in the types, keeping decisions separate from side effects, and not creating extra services or classes unless they own something real.
One of the main parts is a mirrored-type check that runs before and after changes.
Before editing, Codex checks the boundary it is working with and looks for an existing source of truth. That might be a Zod schema, a runtime object, a function return type, a generated Prisma or Drizzle type, an OpenAPI contract, or a handwritten domain type.
The check is light on purpose. It doesn’t force Codex to add more schemas, brands, helpers, or abstractions. It just makes it check what already owns the shape before creating another version of it.
After the edit, it runs a proper source-of-truth audit. That compares changed types against schemas, generated contracts, runtime values, factory returns, and existing exports.
For example, Codex might write:
type RouteName = "home" | "billing" | "admin";
const routes = {
home: "/",
billing: "/billing",
admin: "/admin",
} as const;
The audit can see that "RouteName" is just a second copy of information already stored in "routes", so the better version is:
const routes = {
home: "/",
billing: "/billing",
admin: "/admin",
} as const;
type RouteName = keyof typeof routes;
It does the same kind of check for interfaces that mirror Zod schemas, copied generated types, duplicated DTOs, and schemas where "z.input" and "z.output" are different because the data gets transformed.
It also understands that similar types can be intentional. A transport DTO and a domain model don’t always represent the same thing. Those cases can be left alone instead of being treated as errors.
The post-change audit separates actual problems, possible drift, acceptable choices, and the smallest useful fix.
The TypeScript pack also has routed rules for errors, Zod boundaries, async workflows, cancellation, workers, HTTP handling, database access, generated clients, functional core/procedural shell architecture, and anti-regression checks.
The other main part of the project is the Pragmatic Codex Schema Factory.
The factory takes the same Scheme template and uses it to build a Codex setup for another project. It isn’t a normal code generator. It generates the instruction and routing environment that Codex will use while working in that repository.
It can create:
AGENTS.md
.ai-rules/
.agents/skills/
.codex/
docs/
prompts/
templates/
The process starts with planner mode. Codex asks about the actual project before generating anything: the framework, database, validation approach, error handling, architecture, directory layout, naming rules, and other conventions.
It then produces a blueprint showing both the application structure and the proposed AI rules structure. Nothing gets written until that blueprint is approved.
Once it is approved, the factory compiles it into Codex-native files.
There are four main factory skills.
"$schema-architect" asks the planning questions and designs the blueprint.
"$schema-to-codex" turns an approved blueprint into "AGENTS.md", routed ".ai-rules", Codex skills, and optional ".codex" configuration.
"$codebase-schema-integrator" is for an existing repository. It inspects the repo first and plans where the rules, skills, and Codex files should go without immediately changing anything.
"$schema-auditor" checks an existing setup for duplicated rules, broken routes, missing triggers, context drift, and instructions that no longer match the project.
The point is to keep the human in the loop. The planner asks, the human approves, and then the factory creates the files.
So TheScheme is the reusable template, Pragmatic TypeScript is a working ruleset built from it, and the Codex Schema Factory is the part that can build the same kind of routed setup for other repositories.
Repo:
https://github.com/mayett515/TheScheme
Pragmatic TypeScript router:
Type source-of-truth checker:
Codex Schema Factory: