Reusable coding, commit, architecture, tooling, and documentation standards that can be copied to any project.
- Copy this entire
/standards/directory to your project root - Read each document and adapt the examples to your tech stack
- Copy templates from
/standards/templates/to your project root - Copy
templates/check-decision-traceability.shtoscripts/and enable thedecision-traceabilitycommand in your hook config - Reference these standards in your project's main README
| Document | Purpose | When to Use |
|---|---|---|
| CODING-STANDARDS.md | Code organization, file limits, layering, service independence, runtime wiring guidance | Setting up any new codebase |
| TESTING-STANDARDS.md | Test placement strategy, naming, coverage, and cross-layer verification guidance | Writing maintainable tests |
| COMMIT-STANDARDS.md | Git workflow, conventional commits, agent footers | Any project using version control |
| ARCHITECTURE-PATTERNS.md | System design patterns, monorepo package roles, executable contracts, composition roots, and resilient workflow coordination | Multi-layer, client-server, monorepo, or service-oriented apps |
| TOOLING-STANDARDS.md | Linting, hooks, automation | Enforcing code quality |
| FRONTEND-STANDARDS.md | Declarative rendering, UI synchronization, frontend testing/tooling conventions | Web, desktop UI, and component-heavy frontend codebases |
| DOCUMENTATION-STANDARDS.md | README requirements, comments, algorithm docs | Maintaining readable codebases |
| SECURITY-STANDARDS.md | Boundary validation, path safety, input sanitization, network transport safety | Apps handling user input, file paths, or local IPC |
| CONCURRENCY-STANDARDS.md | Async/threading patterns, async task lifecycle, mutex selection | Multi-threaded or async applications |
| CROSS-PLATFORM-STANDARDS.md | Platform abstraction, file system conventions, CI matrix | Apps targeting multiple OS platforms |
| INTEROP-STANDARDS.md | FFI safety, cross-language boundaries, contract maintenance | Multi-language or native interop projects |
| DEPENDENCY-STANDARDS.md | Dependency evaluation, versioning, auditing, and minimization | Adding or reviewing third-party packages |
| PLAN-STANDARDS.md | Planning workflow, milestones, re-plan triggers, and completion summaries | Multi-file, cross-layer, or staged implementation work |
| LAUNCHER-STANDARDS.md | launcher.sh contract, lifecycle flags, dependency checks, and app startup |
Standardizing app entry points and setup workflows |
| LANGUAGE-BINDINGS-STANDARDS.md | Binding architecture, FFI wrapper design, code generation, type mapping | Exposing a core library to multiple target languages |
| RELEASE-STANDARDS.md | Versioning, changelogs, release artifacts, CI/CD release pipelines | Shipping software to users or downstream consumers |
| ACCESSIBILITY-STANDARDS.md | Semantic HTML, keyboard interaction, ARIA, a11y linting | UI components in web or desktop apps |
Ready-to-use configuration files in /templates/:
| Template | Purpose |
|---|---|
| README-TEMPLATE.md | Directory documentation template |
| PLAN-TEMPLATE.md | Implementation plan template |
| PULL_REQUEST_TEMPLATE.md | PR checklist for decision traceability |
| check-decision-traceability.sh | CI/hook script to enforce README/ADR decision updates |
| lefthook.yml | Pre-commit hook configuration |
| .editorconfig | Editor formatting settings |
These standards are intentionally generic. When adopting them:
- Replace placeholders - Look for
[YOUR-...]markers - Add tech-specific rules - Extend with language-specific conventions
- Define your scopes - Map commit scopes to your project structure
- Configure tooling - Adapt hook commands to your build tools
These standards are provided as-is for free use in any project.