Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →doccker/async-task-pattern
当 API/任务可能执行超过 10 秒（批量数据处理、远程 API 批量调用、全表扫描、跨租户聚合）时触发。防止同步接口被网关 30s 超时切断、用户重复点击触发并发、状态缓存内存泄漏等问题。提供异步任务状态机标准模板。
Passed 22 of 22 test cases with the skill, and 17 of 22 without it.
and 4 more in the full report
5 fixed17 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
A developer configures `@Scheduled` to purge all items from the state cache map every 10 minutes. Why does this cause bugs for active users and how should the removal predicate be written?
| Checked | Without skill | With skill |
|---|---|---|
| Explains that unconditional eviction destroys tracking state for active RUNNING tasks | Missed | Passed |
| Restricts eviction filter to finished tasks whose completion time exceeds TTL | Missed | Passed |
The instructions your model reads when the skill loads.
当一个操作可能跑超过 10 秒，必须改成 triggerAsync() + getStatus() 的异步状态机模式。
不要让用户盯着一个会超时的 loading 转圈，更不要让他点第二下。
与
query-performance-safety配合：先用后者把同步性能压到能跑完的范围；只有"再优化也压不到 10s 以内"时，才走本规范。
只要满足任一条件，就属于本 skill 的覆盖范围：
场景: 6000 条商品查重，同步接口 30s 超时；前端无回执，用户重复点击。
// ❌ HTTP 请求线程内串行跑 N 次远程调用 + JPA 写库
@PostMapping("/duplicates/check")
public ApiResponse<Map<String, List<ProductDTO>>> checkDuplicates() {
return ApiResponse.success(productService.findDuplicateProducts());
// 6000 条 × 4 次隐藏查询 = 24000 次 SQL，必然 > 30s
}
后果：
test cases passed, vs 17 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.