القائمة
Use when TypeScript code coordinates async work — Promise.all vs sequential, bounded concurrency, AbortSignal cancellation, cleanup/teardown, or process lifecycle (SIGTERM, graceful shutdown).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when designing, reviewing, refactoring, or implementing code that should stay simple, testable, readable, and sustainable. Applies principles for investigating before changes, keeping few layers, making I/O explicit, using dependencies deliberately, organizing by feature, naming consistently, and presenting plans progressively.
Makes answers easier to start reading, scan, resume, and understand without losing important detail. Uses useful-answer-first structure, short paragraphs, clear literal headings, simple language, preserved nuance, natural voice, and small ASCII diagrams when they clarify structure or flow.
Use when working on TypeScript code and needing to choose the smallest focused TypeScript skill for coding standards, boundaries, composition, configs, async control, error handling, observability, security, or testing.
Use when TypeScript code moves provider, SDK, API, request, response, generated, or raw input shapes across owned application boundaries.
Use when TypeScript work involves naming, abstractions, classes, local reasoning, semantic centers, full cutovers, type assertions, or design cleanup.
Use when TypeScript work involves dependency construction, composition roots, factories, lifecycle, scope, singletons, caching, or runtime provider selection.
| name | typescript-async |
| description | Use when TypeScript code coordinates async work — Promise.all vs sequential, bounded concurrency, AbortSignal cancellation, cleanup/teardown, or process lifecycle (SIGTERM, graceful shutdown). |
Use this skill when async coordination is the question: should this be parallel? Can it be cancelled? What cleans up if it fails halfway? What happens at SIGTERM?
| If you see... | Read |
|---|---|
sequential awaits for independent operations, or Promise.all question | rules/parallel-and-dependencies.md |
500 IDs in Promise.all causing rate-limit, batching, p-limit, p-map | rules/parallel-and-dependencies.md |
fetch without AbortSignal, query that should cancel on unmount, hanging request | rules/cancellation-and-abort.md |
resource left open on error, missing finally, using/Disposable question | rules/cleanup-and-teardown.md |
SIGTERM, graceful shutdown, unhandledRejection, process.on, draining requests | rules/process-lifecycle.md |
retry loop, exponential backoff, jitter, Retry-After, idempotency key | rules/retry-and-backoff.md |
AbortSignal / AbortController.finally, using, dispose).../typescript-composition/rules/dependency-scope.md).../typescript-error-handling/).../typescript-observability/rules/tracing-boundary.md).../typescript-error-handling/rules/error-classification.md); this skill owns the retry mechanism, not the retry decision.Sequential await is correct when one operation needs the previous result. Promise.all for independent operations. Bound concurrency when the input set can grow unbounded. Pass AbortSignal as a capability when an operation may be cancelled. Clean up resources in finally or with using. Handle SIGTERM at the process boundary so requests drain instead of being killed mid-flight.