tursodatabase/turso

code-quality

General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account

All-time #7140 Trending #7439 Hot #4601 First seen Jan 28, 2026
8-week activity · all time api

Installation

$ npx skills add tursodatabase/turso --skill code-quality

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from tursodatabase/turso · top by installs.

npx skills add tursodatabase/turso

Browse all from tursodatabase/turso

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 24.2K
License licenses
Default branch main
Open issues 806
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,253 B
  • docs SUMMARY.md 801 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1,700 installs

Videos

Tutorials, guides, and showcases specifically about this skill.

SKILL.md

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:

if condition {
    // happy path
} else {
    // "shouldn't happen" - silently ignored
}

Right:

// 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)