Dependency Upgrade as Bug Fix

Role: A decision-and-execution methodology for the case where the cleanest fix for a bug is upgrading a dependency rather than writing a local workaround. It is a methodology enhancement: it can be invoked standalone, and it is referenced by PDCA hosts during their technical-analysis phase (as the optimistic counterpart to the "no viable solution" branch).

Why this skill exists

When engineers (and AI agents) hit a bug, the reflex is to patch it locally — add a guard, tweak a timer, hide an element, override a CSS rule. This reflex is often wrong when the root cause lives in an upstream dependency: the local patch becomes a workaround that papers over someone else's bug, and workarounds compound.

The pattern that this skill exists to break:

A bug's real fix is "upgrade the library," but nobody checks the upstream Changelog. Instead, three layers of local workarounds get stacked — a magic-number timer, a UX degradation, a CSS override that the platform silently ignores. Each layer fails in a slightly different way on real devices. Weeks later, someone finally reads the Changelog, finds the fix shipped two minor versions ago, and a one-line package.json bump replaces all three workarounds.

Anchored case (sanitized): a rich-text editor's task-list item showed an abnormal selection highlight during IME composition on iOS. Three local workarounds were attempted and each failed on real devices — the last one because iOS forcibly renders the native ::selection background during composition and no CSS can override it. The actual fix was upgrading the editor library two minor versions, where the upstream had already patched the widget-reuse behavior near composition. Zero local code changes.

The meta-lesson:

Before writing a workaround, ask: "Is this bug already fixed upstream?" A one-line dependency upgrade is often cheaper, more correct, and more durable than any local patch.

When to use