knack
← all posts

Claude Code May 2026 Update: The /skills Filter Is the Only Thing That Matters

v2.1.108 shipped four changes. The /skills type-to-filter is the one that earns the upgrade. The other three are polish.

Anthropic shipped Claude Code v2.1.108 on April 14, 2026, and the May 2026 update wave brought it to most installs over the last few weeks. Four headline changes landed: a type-to-filter /skills menu, a live view inside /plugin, a new --plugin-url install flag, and a per-turn token estimator. The release notes bury most of this under bug-fix counts and prompt-caching env vars, so here is what actually changed for someone who lives in the terminal.

One of these is the feature you will notice every hour. The other three are polish. The Claude Code May 2026 update is, in practice, the /skills filter release with extras.

/skills filter: the one that earns the upgrade

Type /skills and the menu now accepts keystrokes as a live filter against names and descriptions. Type pg and you get every Postgres-flavored skill in your install. Type render and you see the Render skill pack. Backspace clears. Enter loads the highlighted skill into the current turn.

Before this, /skills was a scrolling list. If you had thirty-plus skills installed (which most people pulling from public marketplaces do by now), you scrolled. Now you type three characters. That sounds small. It is not. The whole point of progressive disclosure in the skills format is that the model picks the right skill at the right moment, but humans pick skills too, and a filter is how they pick faster. This unblocks the "I know I installed something for X" problem that has been the quiet friction of the skills format since it shipped.

If you publish skills (Knack pushes to the same SKILL.md format and shows up in this filter alongside everything else), the filter rewards good description fields. The matching is substring against name and description, so a skill described as "writes Stripe webhook handlers with idempotency keys" surfaces under stripe, webhook, and idempotency. Vague descriptions disappear.

/plugin live view

/plugin now opens a paneled view: installed plugins on the left, status on the right. Status includes version, source URL, and whether the plugin is currently enabled. Disable and enable happen inline with d and e keystrokes. No more re-running install commands to flip a plugin off.

The live view also shows the plugin marketplace state when you have blockedMarketplaces configured at the enterprise level. If a plugin came from a now-blocked source, you see a red badge next to it. Useful for compliance teams. Probably irrelevant if you are one person on a laptop.

--plugin-url

/plugin --plugin-url https://example.com/foo.zip installs a plugin from a zip archive at a URL for the current session. Dependencies declared in the plugin's package.json install automatically. Session-scoped, so it goes away when you quit. Pair it with --plugin-dir for local zips.

This matters for two cases. First, trying a plugin before committing it to your config. Second, CI runs that need a plugin available for one job. Both real, neither daily.

Per-turn token estimator

Bottom-right of the input pane, you now see a small estimate of how many tokens the current turn will consume before you hit enter. It accounts for the loaded skills, plugin context, recent message history, and your draft. The number updates as you type. It uses the active model's tokenizer, so the value you see is the value the API will bill against.

Two notes. The estimate does not include tool-call expansions, so a turn that triggers fifteen file reads will undercount badly. And the context cost projections that show full per-invocation forecasting did not ship in 2.1.108. Those came later in 2.1.143. For now, treat the number as a rough floor; real spend lands higher once tools fire.

Useful if you are watching spend on Opus 4.7's 1M context window. Mostly invisible otherwise.

Plugin-dependency blocks

A small but correct addition. If plugin B declares plugin A as a dependency in its package.json, you can no longer disable A while B is enabled. Attempting it returns:

error: cannot disable plugin "a": plugin "b" depends on it

Disable B first, then A. The error message names the dependent, which is more than most package managers manage. This came from a recurring footgun where users disabled a low-level plugin and watched three others stop working without explanation. Now they stop you at the door.

What this signals

The May 2026 changes lean plugin-first in tooling but skill-first in the daily loop. Plugins get a UI, a live view, an install flag, and a dependency graph. Skills get a filter. The filter wins more user time, because skills are what people invoke turn by turn, and plugins are what people install once and forget. Anthropic seems to know this. The fact that the skills filter was the lightest engineering lift on this release is the most honest piece of product signal they have shipped this quarter.

Upgrade for

The /skills filter. Run claude --version to check. If you are below 2.1.108, run the upgrade. If you keep more than ten skills installed, the filter pays for itself by Wednesday.

Skip

The token estimator until 2.1.143 fixes the tool-call undercount. The --plugin-url flag unless you are testing or scripting. The /plugin live view is nice but you will use it twice a month.