General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account
Scanned 5/29/2026
Install via CLI
openskills install zjunlp/Skills---
name: code-quality
description: General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account
---
# 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
## 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)
No comments yet. Be the first to comment!
Create Mermaid diagrams for flowcharts, sequences, ERDs, and
Draft release notes and changelog entries from git history or merged PRs between two refs (tags/SHAs/branches), including breaking changes, migrations, and upgrade steps. Use when the user asks for release notes, changelog updates, or a GitHub Release draft.
Explain how claude-mem captures observations, when memory injection kicks in, and where data lives. Use when the user asks "how does claude-mem work?" or "what is this thing doing?".
Review a pull request or contribution deeply, explain it tutorial-style for a maintainer, and produce a polished report artifact such as HTML or Markdown. Use when asked to analyze a PR, explain a contributor's design decisions, compare it with similar systems, or prepare a merge recommendation.
Generate the stable Paperclip release changelog at releases/vYYYY.MDD.P.md by reading commits, changesets, and merged PR context since the last stable tag.