القائمة
General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
How to benchmark and analyze memory usage in Turso using the memory-benchmark crate and dhat heap profiler. Use this skill whenever the user mentions memory usage, memory profiling, allocation tracking, heap analysis, memory regression, memory benchmarking, dhat, or wants to understand where memory is being allocated during SQL workloads. Also use when investigating memory growth in WAL or MVCC mode. IMPORTANT - If you modify the perf/memory crate (add profiles, change CLI flags, change output format, etc.), update this skill document to reflect those changes so it stays accurate for future agents.
Use when working with Turso yield injection or synthetic failure injection machinery for safe resumable state-machine boundaries, including YieldInjector, FailureInjector, YieldPointMarker, inject_transition_yield!, inject_io_yield!, inject_transition_failure!, CommitYieldPoint, CheckpointYieldPoint, CursorYieldPoint, deterministic interleaving tests, abandoned statement/commit tests, and concurrent-simulator yield plans.
How to write tests, when to use each type of test, and how to run them. Contains information about conversion of `.test` to `.sqltest`, and how to write `.sqltest` and rust tests
Overview of Experimental MVCC feature - snapshot isolation, versioning, limitations
Change Data Capture - architecture, entrypoints, bytecode emission, sync engine integration, tests
Information about the differential fuzzer tool, how to run it and use it catch bugs in Turso. Always load this skill when running this tool
| name | code-quality |
| description | General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account |
Production database. Correctness paramount. Crash > corrupt.
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.
Do:
Don't:
When code involves index inserts, deletes, or conflict resolution, double-check the ordering against SQLite. Wrong ordering causes index inconsistencies. and easy to miss.
_vars, re-exports, // removed comments)