Module design discipline from John Ousterhout's A Philosophy of Software Design, depth as the metric (a lot of functionality behind a simple interface), information hiding vs. leakage, the concrete red flags that mark a shallow module, and comparing at least two designs before committing. Use when designing a new module or class, deciding where an interface boundary (seam) should go, reviewing a design for unnecessary complexity, or asking whether something should be split or merged.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Codebase Design
Complexity is the enemy, and the single lever that fights it at the module level is **depth**: a module's value is the ratio of functionality it provides to the size of the interface a caller has to learn. A deep module hides a lot behind a little; a shallow one exposes almost as much as it does. Given a choice, make the interface simpler even if that means the implementation underneath grows; the interface is what every caller pays for, forever; the implementation is paid for once, by whoever maintains it.
## Phase 1: Depth is the metric
- A **deep module**: powerful functionality, a small number of simple things a caller needs to know to use it. A well-designed file system API, or a well-designed HTTP client with a handful of methods that hide connection pooling, retries, and serialization.
- A **shallow module**: an interface about as complicated as what it does. A class with one method that thinly wraps a single library call adds a name to learn without hiding any real complexity; the caller might as well have called the library directly.
…
The line at the top of this page pins the label git:20260809.2a45dbb, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
A 17 of 17 checks passed. Fixed automatic checks with no AI involved, so the same checks give the same answer every run.
pass: Frontmatter block present
pass: Frontmatter declares a name
pass: Frontmatter declares a description
pass: Size between 200 bytes and 200 KB (5636 bytes)
pass: No zero-width or bidi control characters
pass: No instruction hidden inside an HTML comment
pass: No link to an exfiltration or paste host
pass: No credential-shaped string
pass: No instruction to send local credentials anywhere
pass: No text hidden with inline styles
pass: No prompt-injection phrasing
pass: No curl or wget piped into a shell
pass: No recursive delete of root, home or parent
pass: No instruction to read or print local credentials
pass: No base64 blob over 200 characters
pass: No link to a raw IP address
pass: No script tag
Source
GitHub
aethrox/doctrine · 19 stars · license MIT · pushed 2026-09-11 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_2gh2l2to3g6idico
GET https://markdownregistry.com/api/v1/resolve?ref=aethrox/doctrine/codebase-design
GET https://markdownregistry.com/api/v1/blob/e0a14420e23c65000ad54b7632afc62347841144e02dc2494d18a7de718dffca
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
aethrox/doctrine · skills/api-design-standards/SKILL.md · API design discipline grounded in the Microsoft/Google REST guidelines, resource and URL conventions, a chosen…
aethrox/doctrine · skills/architecture-diagram/SKILL.md · Produce a software architecture diagram at the right level of zoom, using diagram as code so it can be shown inline…
aethrox/doctrine · skills/capacity-estimation/SKILL.md · Turn a vague performance requirement into arithmetic before the architecture is chosen, size concurrency with Little's…
aethrox/doctrine · skills/code-review/SKILL.md · Code review discipline: the approval bar is "improves code health," not "perfect," Fowler's code-smell catalog gives…
aethrox/doctrine · skills/code-style-lint/SKILL.md · Discipline for code style and static analysis, adopt the ecosystem's established formatter as the non-negotiable source…
aethrox/doctrine · skills/dependency-upgrade-management/SKILL.md · Discipline for keeping dependencies current and deprecating capabilities safely, an inventory (SBOM) of what's actually…
aethrox/doctrine · skills/diagnosing-bugs/SKILL.md · Systematic debugging discipline based on David Agans' nine rules, understand the system, reproduce reliably, bisect the…
aethrox/doctrine · skills/domain-modeling/SKILL.md · Domain-Driven Design discipline, build a ubiquitous language shared by code and conversation, draw explicit bounded…
aethrox/doctrine · skills/explain-plainly/SKILL.md · Default to explaining technical work in plain language for a non-technical audience, using an existing project glossary…
aethrox/doctrine · skills/grilling/SKILL.md · Interview the user relentlessly, in rounds, to close the gap between what's known and what's needed before acting on a…
aethrox/doctrine · skills/handoff/SKILL.md · Hand off in-progress work, an on-call shift, or an open incident to another person or agent using a fixed four-part…
aethrox/doctrine · skills/improve-codebase-architecture/SKILL.md · Scan a codebase (or a named area of one) for architectural friction, classify each finding by how it was incurred, and…
librechat-ai/librechat · .claude/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
danny-avila/librechat · .claude/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
dcouple/pane · main/src/services/paneChatBundle/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
greenfield-inc/pane · main/src/services/paneChatBundle/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
kunolu/640-skills · sbtd-workflow-onboard/assets/external-skills/stable/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
mxyhi/ok-skills · codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
asymmetric-al/core · .agents/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…