Why knowledge patches exist
You have a training data cutoff. After that date, technologies kept evolving: new APIs shipped, defaults changed, functions were deprecated, security vulnerabilities forced version bumps. Users run the latest versions — they have to, for security and new features — so the code they need you to write targets APIs you may never have seen.
The problem is that stale knowledge feels identical to current knowledge from the inside. You'll feel confident about an API that was redesigned six months ago. You'll reach for a function that was deprecated. You'll miss a new feature that's now the idiomatic solution. And you won't notice, because your confidence comes from real training data — it's just not current.
Knowledge patches fix this. Each one contains only what changed since your cutoff for one technology — curated, verified, high signal. Loading one takes a moment. Producing plausible but broken code, then debugging it with the user, takes much longer and consumes more money.
How to use them
Before working with a patched technology — writing code, answering questions, reviewing, planning, debugging, anything — load the matching patch:
- Identify which technologies the task involves
- Check if any installed
*-knowledge-patchskill matches - Invoke via
Skill: <name>(e.g.,Skill: rust-knowledge-patch) before proceeding
Priority when sources conflict: Knowledge patch > project docs > training data.
This applies to all tasks, not just writing code. Wrong answers in reviews, plans, or recommendations are just as costly as wrong code. If a patch exists for the technology you're about to work with, load it first.