nginx-c-module-design
nginx.org C Module Directive Design Best Practices
Comprehensive directive design guide for nginx C module authors, focused on creating clear, consistent, and admin-friendly configuration interfaces. Contains 46 rules across 8 categories, prioritized by impact to guide decisions about what to expose, how to name it, and how to evolve it safely.
When to Apply
Reference these guidelines when:
- Deciding which values to expose as directives vs hardcode
- Naming new directives and choosing argument types
- Selecting scope placement (http, server, location)
- Setting default values and validation behavior
- Designing nginx variables for runtime data
- Deprecating or renaming existing directives
Companion Skills
This skill focuses on design decisions (the "what" and "why"). For implementation mechanics, see:
- nginx-c-modules — C implementation: memory pools, request lifecycle, config parsing, handlers, filters
- nginx-c-perf — Performance: buffers, connections, locks, caching, timeouts
- nginx-c-debug — Debugging: crash diagnosis, GDB, tracing, sanitizers
Rule Categories by Priority
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | Exposure Decisions | CRITICAL | expose- |
| 2 | Naming Conventions | CRITICAL | naming- |
| 3 | Directive Types | HIGH | type- |
| 4 | Scope Design | HIGH | scope- |
| 5 | Default Values | MEDIUM-HIGH | default- |
| 6 | Validation & Error Messages | MEDIUM | valid- |
| 7 | Variable Design | MEDIUM | var- |
| 8 | Evolution & Compatibility | LOW-MEDIUM | compat- |
Quick Reference
1. Exposure Decisions (CRITICAL)
expose-configurable-vs-hardcode- Framework for Configurable vs Hardcoded Valuesexpose-escape-hatch- Provide Escape Hatches for Hardcoded Defaultsexpose-feature-gate- Use Feature Gates for Optional Behaviorexpose-too-many-directives- Avoid Over-Configurationexpose-path-resource- Always Expose External Resource Pathsexpose-security-surface- Audit Security Implications of Every Exposed Directiveexpose-environment-dependent- Expose Values That Vary by Deployment Environment
2. Naming Conventions (CRITICAL)
naming-module-prefix- Use a Consistent Module Prefix for All Directivesnaming-sub-prefix-groups- Group Related Directives with Sub-Prefixesnaming-noun-over-verb- Prefer Noun Phrases for Directive Namesnaming-no-abbreviations- Avoid Custom Abbreviations in Directive Namesnaming-cross-module-consistency- Mirror Nginx Core Suffix Patterns for Analogous Directivesnaming-lowercase-underscore- Use Lowercase with Underscores Only
3. Directive Types (HIGH)
type-flag-for-toggles- Use NGX_CONF_FLAG for Binary Togglestype-enum-over-string- Use Enum Slot for Known Value Setstype-time-size-units- Use Time and Size Slot Functions for Time and Size Valuestype-take-n-fixed-args- Use TAKE1/TAKE2/TAKE12 for Fixed Argument Countstype-one-more-lists- Use 1MORE for Variable-Length Value Liststype-avoid-block- Avoid Block Directives for Featurestype-custom-handler-complex- Use Custom Handlers for Complex Directive Parsing
4. Scope Design (HIGH)
scope-default-three-levels- Default to http + server + location Scopescope-http-only-shared-resources- Restrict Shared Resource Directives to http Level Onlyscope-server-connection-level- Use http + server Scope for Connection-Level Settingsscope-avoid-if-context- Do Not Support the if Context Unless Fully Testedscope-location-path-operations- Restrict Path-Routing Directives to Location Context
5. Default Values (MEDIUM-HIGH)
default-zero-config-safe- Ensure Zero-Config Produces Safe Behaviordefault-performance-optin- Make Performance Features Opt-Indefault-safety-on- Default Security Settings to Restrictive Valuesdefault-generous-timeouts- Default Timeouts to Generous Valuesdefault-zero-unlimited- Use Zero to Mean Unlimited or Disabled for Numeric Limitsdefault-platform-aware-buffers- Use Platform-Aware Buffer Size Defaults
6. Validation & Error Messages (MEDIUM)
valid-parse-time-check- Validate All Directive Values at Config Parse Timevalid-show-invalid-value- Include the Invalid Value in Error Messagesvalid-suggest-range- Include Valid Range or Format in Error Messagesvalid-conflict-detection- Detect Conflicting Directives at Merge Timevalid-actionable-guidance- Provide Actionable Guidance in Error Messages
7. Variable Design (MEDIUM)
var-runtime-data-only- Expose Variables for Per-Request Runtime Data Onlyvar-naming-convention- Name Variables with Module Prefix and Descriptive Suffixvar-dynamic-prefix- Use Dynamic Prefix Variables for Key-Value Datavar-lazy-evaluation- Leverage Lazy Evaluation for Expensive Variablesvar-in-directive-values- Support Variables in Directive Values Only When Per-Request Variation Is Neededvar-read-only-diagnostics- Expose Read-Only Diagnostic Variables for Observability
8. Evolution & Compatibility (LOW-MEDIUM)
compat-deprecation-warning- Log Warnings for Deprecated Directives Before Removalcompat-alias-old-directive- Keep Old Directive Name as an Aliascompat-multi-version-window- Maintain a Multi-Version Deprecation Windowcompat-document-migration- Document Migration Path in Both Old and New Directive Documentation
How to Use
Read individual reference files for detailed explanations and code examples:
- Section definitions - Category structure and impact levels
- Rule template - Template for adding new rules
Reference Files
| File | Description |
|---|---|
| references/_sections.md | Category definitions and ordering |
| assets/templates/_template.md | Template for new rules |
| metadata.json | Version and reference information |
More from pproenca/dot-skills
zod
Zod schema validation best practices for type safety, parsing, and error handling. This skill should be used when defining z.object schemas, using z.string validations, safeParse, or z.infer. This skill does NOT cover React Hook Form integration patterns (use react-hook-form skill) or OpenAPI client generation (use orval skill).
2.0Kclean-architecture
Clean Architecture principles and best practices from Robert C. Martin's book. This skill should be used when designing software systems, reviewing code structure, or refactoring applications to achieve better separation of concerns. Triggers on tasks involving layers, boundaries, dependency direction, entities, use cases, or system architecture.
1.4Kemilkowal-animations
Emil Kowalski's animation best practices for web interfaces. Use when writing, reviewing, or implementing animations in React, CSS, or Framer Motion. Triggers on tasks involving transitions, easing, gestures, toasts, drawers, or motion.
924vitest
Vitest testing framework patterns for test setup, async testing, mocking with vi.*, snapshots, and test performance (formerly test-vitest). This skill should be used when writing or debugging Vitest tests. This skill does NOT cover TDD methodology (use test-tdd skill), API mocking with MSW (use test-msw skill), or Jest-specific APIs.
909typescript
This skill should be used when the user asks to "optimize TypeScript performance", "speed up tsc compilation", "configure tsconfig.json", "fix type errors", "improve async patterns", or encounters TS errors (TS2322, TS2339, "is not assignable to"). Also triggers on .ts, .tsx, .d.ts file work involving type definitions, module organization, or memory management. Does NOT cover TypeScript basics, framework-specific patterns, or testing.
824nuqs
nuqs (type-safe URL query state) best practices for Next.js applications. This skill should be used when writing, reviewing, or refactoring code that uses nuqs for URL state management. Triggers on tasks involving useQueryState, useQueryStates, search params, URL state, query parameters, nuqs parsers, or Next.js routing with state.
737