What this prompt does
This prompt implements an async Rust application built on Tokio rather than a vague example. You set [app_purpose] and the AI covers the full async surface: runtime configuration choosing between multi-threaded and current-thread, properly Future-typed async functions, concurrent task spawning with tokio::spawn and JoinSet, and channel patterns matched to roles. It also explains exactly where Pin, Unpin, and Send plus Sync bounds appear, which is precisely where async Rust newcomers get stuck and give up.
The variables map directly to your workload's structure. [channel_types] and [channel_use_cases] pick the right channel per role, with mpsc for work distribution, broadcast for shutdown signals, and oneshot for responses, while [select_sources] drives a tokio::select! multiplexer over your real event sources. [stream_use_case] sets up tokio-stream processing with backpressure, and [external_service] chooses the connection pool, deadpool or bb8. Choosing the correct channel per role and getting cancellation clean with select is where most async bugs actually live.
When to use it
- Building an I/O-bound Rust app like a crawler or concurrent network fetcher
- Choosing the right Tokio channel type for each distinct role in your system
- Multiplexing multiple event sources cleanly with a single tokio::select! loop
- Adding connection pooling for a database or external service under load
- Handling timeouts and cancellation correctly across async boundaries
- Profiling task scheduling with tokio-console to find the real bottlenecks
Example output
You get an async application skeleton with explicit Tokio runtime configuration, async functions with proper Future types, and concurrent task spawning via tokio::spawn and JoinSet. It wires the chosen [channel_types] to their [channel_use_cases], a tokio::select! loop over your [select_sources], tokio-stream processing with backpressure, timeout and cancellation handling via tokio::time, a connection pool for [external_service], and tracing instrumentation throughout so tokio-console can profile where tasks actually spend their time. Timeouts and cancellation are handled through tokio::time, so a stuck request cannot pin a task open indefinitely and quietly leak resources.
Pro tips
- Describe
[app_purpose]concretely; whether the work is I/O- or CPU-bound changes the runtime configuration choice - Map
[channel_types]to roles deliberately: mpsc for queues, broadcast for fan-out signals, oneshot for a single reply - Keep the shutdown signal in
[select_sources]so cancellation is clean and graceful rather than abrupt - Instrument everything with tracing so tokio-console can actually show you where the time is going
- Set
[external_service]accurately so the pool, deadpool or bb8, matches the real dependency you are calling - Size the connection pool to your concurrency so spawned tasks do not all block waiting on a starved pool under load
- Mind the Send plus Sync bounds the AI flags; ignoring them is a common source of confusing spawn errors
