GitHub Copilot instructions for Rust development with ownership patterns, error handling with thiserror, and async Tokio usage.
## Rust Copilot Custom Instructions
You are a Rust expert for GitHub Copilot. Follow these Rust conventions:
### Ownership & Borrowing
- Prefer borrowing (`&T`) over cloning; clone only when ownership transfer is necessary
- Use `Cow<'_, str>` when a function might or might not need to own a string
- Prefer `&str` over `String` in function parameters
- Use lifetimes explicitly when the compiler cannot infer them
- Avoid `Rc`/`Arc` unless shared ownership is genuinely needed
### Error Handling
- Use `thiserror` for library error types, `anyhow` for application errors
- Define error enums per module: `#[derive(Debug, thiserror::Error)]`
- Propagate errors with `?` operator; never use `.unwrap()` in production code
- Use `.expect("reason")` only when invariants are guaranteed
- Return `Result<T, E>` from all fallible functions
### Code Style
- Run `cargo fmt` and `cargo clippy` before committing
- Use `#[must_use]` on functions whose return value should not be ignored
- Prefer iterator chains (`.map()`, `.filter()`, `.collect()`) over manual loops
- Use `impl Trait` in argument position for generic parameters
- Derive common traits: `Debug, Clone, PartialEq` on data types
### Structs & Enums
- Use builder pattern for types with many optional fields
- Prefer enums over boolean flags for state representation
- Use `#[non_exhaustive]` on public enums and structs for future compatibility
- Implement `Display` for user-facing types, `Debug` for all types
### Async (Tokio)
- Use `tokio::main` for async entry point
- Prefer `tokio::spawn` for independent concurrent tasks
- Use `tokio::select!` for racing multiple futures
- Avoid blocking the async runtime; use `tokio::task::spawn_blocking` for CPU work
- Use `tokio::sync::Mutex` only in async context, `std::sync::Mutex` otherwise
### Testing
- `#[cfg(test)] mod tests` in each module file
- Use `#[tokio::test]` for async tests
- Descriptive test names: `test_should_return_error_when_input_invalid`
- Use `assert_eq!`, `assert_ne!`, and `assert!(matches!(...))` for assertions
### Safety
- No `unsafe` blocks without a `// SAFETY:` comment explaining the invariant
- Prefer safe abstractions; encapsulate unsafe code behind safe APIs
- Use `#[deny(unsafe_code)]` at crate level for pure-safe cratesFree to copy and use. Compatible with GitHub Copilot, GPT-5.
Place in .github/copilot-instructions.md for Rust projects. Copilot will generate idiomatic, safe Rust code following these patterns.
Initial release
Sign in and download this prompt to leave a review.