dev-standards defines a universal engineering standard that can apply to almost any development project without assuming a specific topic, stack, architecture, or toolchain.
The standard is designed to remain useful across changing contexts by standardizing engineering behavior rather than domain content.
The standard is organized into three layers:
core: universal rulesprofiles: optional context-heavy practice packsadapters: tool or ecosystem specific application guides
This structure keeps the core small, strict, and broadly reusable.
The universal core consists of twelve rules.
- Scope And Applicability Defines where the standard applies and what it intentionally does not prescribe.
- Repository Contract Defines the minimum discoverable structure of a project repository.
- Configuration And Environment Prevents hardcoded runtime assumptions and hidden machine-specific behavior.
- Change Management Requires coherent, reviewable, and reversible change.
- Decision Records Preserves structural engineering decisions and their rationale.
- Problem Tracking Ensures defects, risks, limitations, and unresolved questions remain visible.
- Dependency Management Makes critical external dependencies explicit and maintainable.
- Verification Requires evidence that meaningful work has been checked.
- Interfaces And Contracts Treats important boundaries as first-class engineering assets.
- Observability Requires enough runtime visibility to diagnose health and failure.
- Security And Risk Requires explicit handling of secrets, unsafe inputs, and risky actions.
- Documentation And Discoverability Keeps essential project knowledge accessible over time.
A rule belongs in the core only if it remains useful:
- across project subjects
- across technology stacks
- across team sizes
- across delivery models
- across tool choices
If a rule is only strong in a recurring project shape, it belongs in a profile. If a rule only makes sense because of a specific tool, it belongs in an adapter.
Profiles add stricter guidance for recurring project shapes.
The initial profile set is:
research-data-mlai-assisted-developmentincident-operationspublic-writing
Profiles are optional. They may be strict when active.
Adapters operationalize the standard in specific tools or ecosystems.
The initial adapter set is:
githubclaude-codeproject-memorypythontypescriptci
Adapters may tighten implementation details but must not redefine the core.
The universal standard does not mandate:
- one programming language
- one framework
- one architecture style
- one branching strategy
- one testing framework
- one deployment model
- one documentation tree
- one AI tool
Those are implementation choices or context-specific practices.
A project adopts the standard by composing:
- the universal core
- zero or more optional profiles
- zero or more adapters
Examples:
corecore + incident-operations + github + cicore + research-data-ml + ai-assisted-development + python
The minimal starter pack includes:
- repository README template
- docs index template
- decision record template
- problem record template
- dependency inventory template
- verification checklist template
- exception record template
- system map template
- module ownership map template
- interface catalog template
- failure memory index template
Projects should migrate by convergence, not by full rewrite.
Recommended path:
- adopt the universal core principles
- add minimum discoverability artifacts
- activate relevant profiles
- activate relevant adapters
- replace local conventions only where necessary