turon_skill

This skill helps you design user-friendly public APIs and async Rust interfaces with Turon-inspired patterns for safe, ergonomic usage.
  • Python

3

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill copyleftdev/sk1llz --skill turon

  • SKILL.md7.3 KB

Overview

This skill codifies API design and async Rust patterns in the style of Aaron Turon. It emphasizes user-first APIs, making illegal states unrepresentable, and designing async code that reads like sync code. Use it to shape public library interfaces, async systems, and ergonomic builders that are hard to use incorrectly.

How this skill works

I inspect intended usage scenarios first and propose API shapes that make the obvious thing the right thing. I recommend concrete patterns: builders, type-state, extension traits, impl Trait return types, and async parity. I also suggest trait implementations, naming, and error shaping so the API is consistent, discoverable, and compiler-enforced where possible.

When to use it

  • Designing public library APIs that must be easy to discover and hard to misuse
  • Creating async APIs that should read and behave like sync equivalents
  • Defining state machines or protocols where order matters (use type-state)
  • Building fluent request/builder patterns or complex constructors
  • Refactoring an existing API to follow Rust conventions and reduce surface area

Best practices

  • Start by writing the ideal usage examples (the code users should write) before implementation
  • Make illegal states unrepresentable with types and prefer compile-time guarantees
  • Favor builders for complex construction and type-state for ordered workflows
  • Keep async and sync APIs parallel; return impl Future or async fn where appropriate
  • Implement standard traits (Debug, Clone, Default) when it improves ergonomics and discovery
  • Use clear, conventional Rust names: new, with_, into_, as_, to_, is_

Example use cases

  • HTTP client with a RequestBuilder that composes headers and sends either sync or async requests
  • Connection/state machine using type-state to enforce connect→authenticate→query order
  • Library exposing an async Repository trait with native async methods or async-trait shim
  • Extension traits adding ergonomic helpers to third-party types (ResultExt for error context/logging)
  • Utility that exposes both blocking and async convenience APIs with clear boundaries

FAQ

Use builders when many optional parameters must be composed; use type-state when you need the compiler to enforce a specific sequence of operations.

Should async APIs mirror sync ones exactly?

Aim for parity in names and behavior so users can switch mental models, but accept minor ergonomic differences when driven by runtime constraints.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
turon skill by copyleftdev/sk1llz | VeilStrat