rust-coder
Skill2 starsChanged 15 days agoMITView on GitHub
Rust coding guide for this monorepo. Use when writing Rust code in any package (desktop, orm, relay, shared, update-signer). Combines Rust API Guidelines with clearly marked project rules for errors, Tokio, tracing, and Clippy. For GPUI code use gpui-coder; for schema changes use diesel-migration.
In this repository8 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cavemanSkill
- diesel-migrationSkill
- gpui-coderSkill
- impeccableSkill
- pen-design-readerSkill
- design-taste-frontendSkill
- ui-ux-pro-maxSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 48
[Official]: Use as_, to_, into_ consistently for conversions
- Very specific: line 49
[Official]: Use iter, iter_mut, into_iter for iterator-producing methods
- Very specific: line 50
[Official]: All public types should implement Debug
- Distinctive: line 51
[Official]: Prefer private fields and controlled construction
- Distinctive: line 52
[Official]: Avoid boolean flag parameters.
- Very specific: line 56
[Official]: Use cargo fmt defaults; do not customize rustfmt casually
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rust Coder - Convention Guide
Rust conventions for this monorepo.
- Official = Rust API Guidelines / rustfmt / standard Rust conventions
- Project = local rules for this repo
- Common = widespread Rust practice, not a strict official requirement
Forbidden Patterns
// ❌ NEVER (Project)
unsafe {
do_unsafe_work();
}
value.unwrap();
todo!();
dbg!(&value);
// ❌ AVOID IN LIBRARY CODE (Project)
value.expect("must exist");Quick Reference
Naming
| Type | Convention | Example | Source |
| Files/dirs | snake_case | message_handler.rs | Official |
| Types/traits | UpperCamelCase | MessageHandler, DeviceId | Official |
| Functions/vars | snake_case | handle_message(), device_count | Official |
| Constants/statics | SCREAMING_SNAKE_CASE | MAX_RETRY_COUNT | Official |
| Cargo crate name | kebab-case | update-signer | Official |
| Rust module path | snake_case | update_signer | Official |
Key Rules
- [Project] No
unwrap()outside tests — propagate with?. The one exception ismutex.lock().unwrap(): a poisoned lock is already a crash - [Project]
expect("why this cannot fail")is allowed in tests and for startup invariants (the Tokio runtime, a backend task that panicked); not for input or I/O - [Project] No
unsafein this repo - [Official] Use
as_,to_,into_consistently for conversions - [Official] Use
iter,iter_mut,into_iterfor iterator-producing methods - [Official] All public types should implement
Debug - [Official] Prefer private fields and controlled construction
- [Official] Avoid boolean flag parameters; prefer domain types
- [Official] Destructors must not fail
- [Project] Async work runs on Tokio; log with
tracingmacros, neverprintln! - [Official] Public APIs should be documented and include examples where useful
- [Official] Use
cargo fmtdefaults; do not customize rustfmt casually
Error Handling
Two styles, by package (Project):
// packages/desktop: Result<T, String>. The string reaches the user, so say what failed.
pub fn init_pool(database_path: &Path) -> Result<DbPool, String> {
r2d2::Pool::builder()
.build(manager)
.map_err(|error| format!("failed to open database: {error}"))
}
// packages/relay: anyhow at the binary's edge.
use anyhow::{Context, Result};
async fn connect(addr: &str) -> Result<TcpStream> {
TcpStream::connect(addr)
.await
.with_context(|| format!("failed to connect to {addr}"))
}Match the package you are in. Do not add anyhow or thiserror to desktop.
Async Pattern
// Blocking work (SQLite, file I/O) leaves the async thread.
tokio::task::spawn_blocking(move || operation(&mut connection)).await
// Log with structured fields, message last.
tracing::warn!(error, "Failed to save setting");The desktop app owns one Tokio runtime (crate::app::runtime()); GPUI's executor is separate. UI
code reaches backend futures through backend(...) in ui/bridge.rs (see gpui-coder).
Detailed References
- Naming conventions (types, functions, traits, modules) →
references/naming.md - Error handling (String errors, anyhow, domain errors, validation) →
references/error-handling.md - Async & Tokio (spawning, cancellation, streams, tracing) →
references/async-tokio.md - API design (constructors, builders, conversions, newtypes, traits) →
references/api-design.md - Clippy & correctness (lint policy, commands, common fixes) →
references/clippy.md - Anti-patterns (official + project anti-patterns, clearly labeled) →
references/anti-patterns.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

