sota-api-design
State-of-the-art API design and audit guidance (2026) covering REST/HTTP, GraphQL, gRPC, WebSockets/SSE/realtime, webhooks,…
State-of-the-art rules for writing and auditing asynchronous and concurrent code across runtimes (Python asyncio, JS/Node, Go, Rust, JVM). Use when building anything with async/await, threads, processes, event loops, task groups, channels, or queues — and when auditing existing
Claude Code
$ npx -y skills add martinholovsky/SOTA-skills --skill sota-async-concurrency --agent claude-code
Codex
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a codex -y
Cursor
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a cursor -y
Gemini CLI
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a gemini-cli -y
GitHub Copilot
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a github-copilot -y
OpenCode
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a opencode -y
Windsurf
$ npx skills add martinholovsky/SOTA-skills --skill sota-async-concurrency -a windsurf -y
name: sota-async-concurrency description: >- State-of-the-art rules for writing and auditing asynchronous and concurrent code across runtimes (Python asyncio, JS/Node, Go, Rust, JVM). Use when building anything with async/await, threads, processes, event loops, task groups, channels, or queues — and when auditing existing code for race conditions, deadlocks, leaked tasks, blocked event loops, missing cancellation, or backpressure failures. Not for latency/throughput profiling and optimization — use sota-performance. Trigger keywords: async, await, concurrency, parallelism, threads, race condition, deadlock, event loop, channels, queues, semaphore, mutex, cancellation, timeout, backpressure, task group, goroutine, tokio, asyncio.
Concurrency bugs are the most expensive class of defect: they pass tests, ship, and then corrupt data or hang production under load. This skill encodes the 2026 state of the art for concurrent design and the bug catalog auditors need to spot defects **by reading code**, without reproducing them. Concepts are cross-language; per-runtime notes are inlined where semantics genuinely differ (GIL, goroutine scheduling, tokio executors, Node's single loop).
Two operating modes. Pick one explicitly before starting.
When writing new concurrent code:
1. **Classify the workload first.** I/O-bound → async/event loop. CPU-bound → threads (if runtime has real parallelism) or processes. Mixed → async front-end + bounded worker pool. Read [`rules/01`](rules/01-models-and-structure.md) before choosing; on an event loop, keep blocking and CPU work off it ([`rules/04`](rules/04-event-loop-hygiene.md)). 2. **Structured concurrency is the default.** Every task lives inside a scope (TaskGroup / nursery / errgroup / JoinSet) that joins or cancels it. Spawning a task with no owner is a design smell requiring written justification. 3. **Bound everything.** Every queue, channel, connection pool, in-flight request set, and spawn loop gets an explicit capacity. Unbounded = OOM with a delay timer. 4. **Every await gets a timeout policy** — a number, or a documented reason why it inherits one from an enclosing scope ([`rules/05`](rules/05-cancellation-timeouts-shutdown.md)). 5. **Cancellation is a feature you build, not an exception you ignore.** Propagate context/AbortSignal/CancelledError; clean up in finally blocks; design shutdown order (stop intake → drain → deadline → force) ([`rules/05`](rules/05-cancellation-timeouts-shutdown.md)). 6. **Shared mutable state needs an owner.** Prefer message passing or single-owner tasks; if you must lock, define lock ordering and never hold a lock across an await. Races vs race conditions, atomicity and TOCTOU: [`rules/02`](rules/02-correctness.md); choosing the primitive: [`rules/03`](rules/03-primitives.md). Ambient per-request context (tenant, user) is reset when the request ends, or a reused worker serves the next request with it: [`rules/07`](rules/07-audit-bug-catalog.md) §3. 7. Re-read the audit checklists at the end of each rules file against your own diff before declaring done.
**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.
When auditing existing code, you find races, deadlocks, and leaks by reading — grep is your debugger. Workflow:
1. **Map the concurrency topology.** What spawns tasks/threads? What shares state? What are the queues and their bounds? Draw the lock set and the channel graph mentally before judging any line. 2. **Sweep with targeted greps**, then read each hit in context:
handle; bare `go func(`; `.then(` with no `.catch(`; floating promises; `tokio::spawn` whose JoinHandle is dropped.
`fs.readFileSync`, `bcrypt.hashSync`, `std::thread::sleep` inside async fns.
`await` / `.await`.
producers, `unbounded_channel`, spawn-in-loop with no semaphore.
on shared counters without atomics/locks. 3. **For each suspect, prove the interleaving.** State the two (or more) execution orders and which one breaks. A finding without an interleaving is a style note, not a concurrency bug. 4. Read [`rules/07`](rules/07-audit-bug-catalog.md) for the full bug catalog with signatures.
| Severity | Criteria | Examples | |---|---|---| | CRITICAL | Data corruption, deadlock, or unbounded resource growth reachable under normal load | Lost-update race on money/state; lock-ordering deadlock on hot path; unbounded queue fed by network input | | HIGH | Hang, leak, or wrong result under plausible (load/error/timeout) conditions | Fire-and-forget swallowing exceptions; no timeout on external call; lock held across await; blocking call on event loop | | MEDIUM | Degraded behavior, starvation, or fragility under contention | Writer starvation on RwLock; missing jitter on retries; thundering herd on cache expiry; spurious-wakeup-unsafe condvar wait | | LOW | Latent hazard or convention violation with no current trigger | Orphanable task that today happens to finish first; missing cancellation propagation in a path that is never cancelled yet |
Escalate one level when the affected state is money, auth, or durability.
[SEVERITY] file:line — short title Race window / failure mode: the exact inter
Make your AI coding assistant build and audit like your most senior engineer. Your assistant is brilliant — it just doesn't know your standards, and it forgets the ones it does know as the task grows long.
State-of-the-art API design and audit guidance (2026) covering REST/HTTP, GraphQL, gRPC, WebSockets/SSE/realtime, webhooks,…
State-of-the-art software and system architecture rules (2026) for both building and auditing. Use when designing, building,…
State-of-the-art C and C++ engineering rules that Claude applies when writing or auditing C/C++. Covers modern idioms (RAII,…
State-of-the-art CLI and developer-tool UX guidance (2026) covering command and flag design, output and interaction…
State-of-the-art cloud infrastructure architecture (2026). Applies when designing, building, or auditing cloud environments on…
Secure coding and security auditing rules. Use whenever BUILDING or modifying code that crosses a trust boundary — endpoints,…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.