Code Quality
Apply Turso/Limbo production-grade Rust correctness rules whenever you or an agent writes or reviews database code.
Overview
Code Quality is a journey-wide agent skill that teaches Turso production Rust correctness—assert invariants, crash on integrity risk, and avoid silent failure—whenever a solo builder writes or reviews database code.
Install
npx skills add https://github.com/tursodatabase/turso --skill code-qualityWhat is this skill?
- Production DB mindset: crash preferred over silent corruption
- Correctness rules: no hacks, assert often, handle all errors
- Rust patterns: illegal states unrepresentable, exhaustive matches, minimal allocations
- If-statement guidance: happy-path-only branches use assert/unreachable/Err
- Comment rules: document why, avoid AI-chatter and temporal markers
- 4 core correctness rules
- Wrong vs right if-statement examples
- Do/Don't comment lists
Adoption & trust: 1.2k installs on skills.sh; 19.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need agents to write Rust against a production database without swallowing errors, papering over impossible states, or commenting like a chat transcript.
Who is it for?
Contributors and agents working on Turso/Limbo Rust who want a single authoritative quality bar during implementation and review.
Skip if: Greenfield prototypes where data loss is acceptable, or non-Rust stacks where these invariants do not apply.
When should I use this skill?
When writing code always take these into account (Turso general correctness, Rust patterns, comments, avoiding over-engineering).
What do I get? / Deliverables
Code changes follow explicit correctness, Rust idioms, and comment standards so invalid states fail loudly instead of corrupting data.
- Code conforming to Turso correctness rubric
- Review-ready Rust with documented invariants
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Agent implements a new storage path and must use assert/unreachable instead of empty else branches.
Pre-merge pass checks comments explain why invariants exist, not what the next line does.
Hotfix for an edge-case bug adds assertions so corrupting state cannot continue execution.
Tests are written to expose impossible states rather than only happy paths.
How it compares
Standing procedural quality guide—not a formatter, generic linter config, or security audit skill.
Common Questions / FAQ
Who is code-quality for?
Rust contributors and agent-assisted developers on Turso database work who need correctness-first patterns baked into every coding session.
When should I use code-quality?
Across Build backend work, Ship review before merge, and Operate iteration when fixing Limbo bugs—any time SKILL.md says to take these rules into account while writing code.
Is code-quality safe to install?
It is documentation-only guidance with no runtime hooks; review the Security Audits panel on this page for the skill package source.
SKILL.md
READMESKILL.md - Code Quality
# Code Quality Guide ## Core Principle Production database. Correctness paramount. Crash > corrupt. ## Correctness Rules 1. **No workarounds or quick hacks.** Handle all errors, check invariants 2. **Assert often.** Never silently fail or swallow edge cases 3. **Crash on invalid state** if it risks data integrity. Don't continue in undefined state 4. **Consider edge cases.** On long enough timeline, all possible bugs will happen ## Rust Patterns - Make illegal states unrepresentable - Exhaustive pattern matching - Prefer enums over strings/sentinels - Minimize heap allocations - Write CPU-friendly code (microsecond = long time) ## If-Statements Wrong: ```rust if condition { // happy path } else { // "shouldn't happen" - silently ignored } ``` Right: ```rust // If only one branch should ever be hit: assert!(condition, "invariant violated: ..."); // OR return Err(LimboError::InternalError("unexpected state".into())); // OR unreachable!("impossible state: ..."); ``` Use if-statements only when both branches are expected paths. ## Comments **Do:** - Document WHY, not what - Document functions, structs, enums, variants - Focus on why something is necessary **Don't:** - Comments that repeat code - References to AI conversations ("This test should trigger the bug") - Temporal markers ("added", "existing code", "Phase 1") ## Avoid Over-Engineering - Only changes directly requested or clearly necessary - Don't add features beyond what's asked - Don't add docstrings/comments to unchanged code - Don't add error handling for impossible scenarios - Don't create abstractions for one-time operations - Three similar lines > premature abstraction ## Index Mutations When code involves index inserts, deletes, or conflict resolution, double-check the ordering against SQLite. Wrong ordering causes index inconsistencies. and easy to miss. ## Ensure understanding of IO model - [Async IO model](../async-io-model/SKILL.md) ## Cleanup - Delete unused code completely - No backwards-compat hacks (renamed `_vars`, re-exports, `// removed` comments)