The recommended async simplification can change exception and Promise behavior
Source references: 3The example replaces an async function with a regular function that directly returns the underlying call, despite the Skill requiring identical error behavior. If findById throws before returning a Promise, the original returns a rejected Promise while the rewritten function throws synchronously; Promise object identity can also differ. A declared Promise return type does not rule out these differences.
Callers' try/catch handling, Promise chains, retries, or error reporting may follow a different path, causing an unhandled exception, skipped recovery, or runtime interruption.
This is an explicitly recommended rewrite, but it may violate the Skill's own requirement to preserve error behavior. If `findById` throws synchronously before returning a Promise, the original `async` wrapper produces a rejected Promise, while the rewritten function throws synchronously; callers may therefore fail to catch it as before. Users can require this rewrite only when synchronous throws are ruled out and tests cover the distinction.
### 1. Preserve Behavior ExactlyDon't change what the code does — only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.Show 2 other places
```typescript// SIMPLIFY: Unnecessary async wrapper// Beforeasync function getUser(id: string): Promise<User> { return await userService.findById(id);}// Afterfunction getUser(id: string): Promise<User> { return userService.findById(id);}Don't change what the code does — only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.