From beagle-rust
Reviews Tokio async runtime usage in Rust code: task management, sync primitives, channels, runtime config. For tokio, async/await, spawn, channels.
npx claudepluginhub existential-birds/beagle --plugin beagle-rustThis skill uses the workspace's default tool permissions.
1. **Check Cargo.toml** — Note tokio feature flags (`full`, `rt-multi-thread`, `macros`, `sync`, etc.). Missing features cause confusing compile errors.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
full, rt-multi-thread, macros, sync, etc.). Missing features cause confusing compile errors.#[tokio::main] or manual runtime construction used? Multi-thread vs current-thread?std::fs, std::net, std::thread::sleep, CPU-heavy loops in async functions.Report findings as:
[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.
| Issue Type | Reference |
|---|---|
| Task spawning, JoinHandle, structured concurrency | references/task-management.md |
| Mutex, RwLock, Semaphore, Notify, Barrier | references/sync-primitives.md |
| mpsc, broadcast, oneshot, watch channel patterns | references/channels.md |
multi_thread for I/O-bound, current_thread for simpler cases)#[tokio::test] used for async tests (not manual runtime construction)spawn return values (JoinHandle) are tracked, not silently droppedspawn_blocking used for CPU-heavy or synchronous I/O operationsCancellationToken, select!, or shutdown channels)JoinError (task panic or cancellation) is handled, not just unwrappedtokio::select! branches are cancellation-safetokio::sync::Mutex used when lock is held across .await; std::sync::Mutex for short non-async sectionsSemaphore used for limiting concurrent operations (not ad-hoc counters)RwLock used when read-heavy workload (many readers, infrequent writes)Notify used for simple signaling (not channel overhead)SendError / RecvError handled (indicates other side dropped)Lagged errors handled (receiver fell behind)tokio::time::sleep used instead of std::thread::sleeptokio::time::timeout wraps operations that could hangtokio::time::interval used correctly (.tick().await for periodic work)std::fs::read, std::net::TcpStream) in async context without spawn_blocking.await point (deadlock potential)std::thread::sleep in async function (blocks runtime thread)JoinHandle silently dropped (lost errors, zombie tasks)select! cancellation safety considerationtokio::spawn for trivially small async blocks (overhead > benefit)#[tokio::main] sufficesstd::sync::Mutex where contention is high enough to benefit from tokio's async mutextokio-util utilities (e.g., CancellationToken)JoinSetstd::sync::Mutex for short critical sections — tokio docs recommend this when no .await is inside the locktokio::spawn without explicit join — Valid for background tasks with proper shutdown signaling#[tokio::main(flavor = "current_thread")] in simple binaries — Not every app needs multi-thread runtimeclone() on Arc<T> before spawn — Required for moving into tasks, not unnecessary cloningLoad and follow beagle-rust:review-verification-protocol before reporting any issue.