無料GitHub で公開

rust-best-practices

Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. Use this skill when: (1) writing new Rust code or functions, (2) reviewing or refactoring existing Rust code, (3) deciding between borrowing vs cloning or ownership patterns, (4) implementing error handling with Result types, (5) optimizing Rust code for performance, (6) writing tests or documentation for Rust projects.

dirien/yet-another-agent-harness

インストール方法を見る

含まれるファイル（10）

SKILL.md4.2 KB
references/chapter_01.md16.9 KB
references/chapter_02.md5.3 KB
references/chapter_03.md8.6 KB
references/chapter_04.md6.9 KB
references/chapter_05.md13.8 KB
references/chapter_06.md6.7 KB
references/chapter_07.md8.0 KB
references/chapter_08.md9.9 KB
references/chapter_09.md9.3 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Rust Best Practices

Apply these guidelines when writing or reviewing Rust code. Based on Apollo GraphQL's Rust Best Practices Handbook.

Best Practices Reference

Before reviewing, familiarize yourself with Apollo's Rust best practices. Read ALL relevant chapters in the same turn in parallel. Reference these files when providing feedback:

Chapter 1 - Coding Styles and Idioms: Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments
Chapter 2 - Clippy and Linting: Clippy configuration, important lints, workspace lint setup
Chapter 3 - Performance Mindset: Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
Chapter 4 - Error Handling: Result vs panic, thiserror vs anyhow, error hierarchies
Chapter 5 - Automated Testing: Test naming, one assertion per test, snapshot testing
Chapter 6 - Generics and Dispatch: Static vs dynamic dispatch, trait objects
Chapter 7 - Type State Pattern: Compile-time state safety, when to use it
Chapter 8 - Comments vs Documentation: When to comment, doc comments, rustdoc
Chapter 9 - Understanding Pointers: Thread safety, Send/Sync, pointer types

Quick Reference

Borrowing & Ownership

Prefer &T over .clone() unless ownership transfer is required
Use &str over String, &[T] over Vec<T> in function parameters
Small Copy types (≤24 bytes) can be passed by value
Use Cow<'_, T> when ownership is ambiguous

Error Handling

Return Result<T, E> for fallible operations; avoid panic! in production
Never use unwrap()/expect() outside tests
Use thiserror for library errors, anyhow for binaries only
Prefer ? operator over match chains for error propagation

Performance

Always benchmark with --release flag
Run cargo clippy -- -D clippy::perf for performance hints
Avoid cloning in loops; use .iter() instead of .into_iter() for Copy types
Prefer iterators over manual loops; avoid intermediate .collect() calls

Linting

Run regularly: cargo clippy --all-targets --all-features --locked -- -D warnings

Key lints to watch:

redundant_clone - unnecessary cloning
large_enum_variant - oversized variants (consider boxing)
needless_collect - premature collection

Use #[expect(clippy::lint)] over #[allow(...)] with justification comment.

Testing

Name tests descriptively: process_should_return_error_when_input_empty()
One assertion per test when possible
Use doc tests (///) for public API examples
Consider cargo insta for snapshot testing generated output

Generics & Dispatch

Prefer generics (static dispatch) for performance-critical code
Use dyn Trait only when heterogeneous collections are needed
Box at API boundaries, not internally

Type State Pattern

Encode valid states in the type system to catch invalid operations at compile time:

struct Connection<State> { /* ... */ _state: PhantomData<State> }
struct Disconnected;
struct Connected;

impl Connection<Connected> {
    fn send(&self, data: &[u8]) { /* only connected can send */ }
}

Documentation

// comments explain why (safety, workarounds, design rationale)
/// doc comments explain what and how for public APIs
Every TODO needs a linked issue: // TODO(#42): ...
Enable #![deny(missing_docs)] for libraries

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

agent-ready-go

無料

Prepares Go applications to work effectively with AI coding agents. Use when setting up a new Go project or retrofitting an existing one to ensure: structured JSON logging (slog/Zap/ZeroLog/Logrus), machine-readable command output, thorough golangci-lint configuration, non-interactive CLI design with --yes flags, structured error handling with meaningful exit codes, proper context.Context propagation, graceful shutdown, health check endpoints, and a standardized Makefile. Triggers when a user asks to make their Go app "agent-ready," "AI-friendly," wants to improve agent tooling/observability in a Go project, or needs to audit an existing Go project against agent-readiness best practices.

日本語の概要は準備中です。原文の説明を表示しています。