code-quality

This skill acts as a strict architectural and stylistic gatekeeper for the Turso database development process. It focuses on the mission-critical nature of database engineering where correctness is paramount, and system stability must never be compromised. The skill is designed for engineers contributing to the Turso repository who need to ensure their implementations align with production-grade database standards. It emphasizes that for database internals, crashing in a controlled manner upon encountering an invalid state is vastly superior to allowing silent data corruption.

• Enforces strict Rust patterns such as making illegal states unrepresentable, utilizing exhaustive pattern matching, and avoiding heap allocations in critical hot paths.

• Promotes defensive programming through frequent assertions, invariant checks, and handling all error paths rather than silencing edge cases or using quick hacks.

• Provides guidelines for writing CPU-friendly, cache-conscious code where microsecond-level latency matters, ensuring optimal performance for in-process SQL execution.

• Mandates documentation that explains the 'why' behind complex logic rather than repeating code, and discourages redundant or temporal comments.

• Prevents over-engineering by requiring that changes remain focused on requested features, avoiding premature abstractions, and enforcing cleanup of unused code or legacy hacks.

• Includes specific warnings for index mutations, requiring rigorous cross-referencing with SQLite's internal ordering behavior to prevent data inconsistencies.

• Inputs are typically code snippets, pull requests, or design proposals involving Rust modules for the Turso database.

• Outputs consist of code reviews, refactoring suggestions, or technical guidance that ensures adherence to Turso's core principles of durability and performance.

• Always prioritize data integrity over feature velocity; assume that on a long enough timeline, every edge case bug will occur.

• Use proper error handling mechanisms like Result types and avoid if-else chains that silently ignore unexpected branches; prefer explicit assertions or unreachable macros for impossible logic states.

• Keep implementation focused: if a change does not directly serve a requirement or improve core correctness, it should not be included.