Quick recap from the first post: Agent Skill Sync is a small VS Code / Cursor extension that pulls Cursor rules and skill packages from a GitHub repo (or a custom registry) and drops them where Cursor actually looks, .cursor/rules and .cursor/skills. Free on Open VSX: KeskaLabsAB / agent-skill-sync.

The plugin we showed off in the last post nailed the boring half: getting curated skills out of git and into the editor without a copy-paste ceremony. Then the catalog grew. And the moment a teammate opened the panel, blinked at twenty-something skills, and asked “okay… which of these do I actually want?”, we knew the next problem to solve.

This post is about that. Discovery. Less scrolling, more “oh, that one.”

First, the unsexy bit

Before we could put a recommender on top, the foundation had to behave. A quiet polish pass cleaned up two things you’ll notice mostly because they stopped annoying you:

• First-run reliability: the welcome / setup prompt no longer flickers, double-fires, or leaves you staring at a blank panel on a fresh install.

• Browse tree expand/collapse: nested folders now toggle the way you expect them to. Subtle, deeply annoying when it was wrong.

Onward.

A Recommended tab, finally

We added a third tab to the Skill Manager, next to Manage and Browse, called Recommended. It looks at your workspace and ranks the catalog for you.

“Looks at your workspace” isn’t magic. It reads the ordinary tells:

• which languages the repo uses,

• what’s in package.json / pyproject.toml / Cargo.toml / go.mod (your dependencies),

• a few path markers (Dockerfiles, monorepo configs, etc.),

• which VS Code / Cursor extensions you have installed,

• and AGENTS.md if you keep one.

Each catalog skill can declare triggers in its SKILL.md (languages, dependencies, files, keywords). The tab cross-references the two and surfaces the matches with a small chip telling you why, “Keywords matched AGENTS.md [rest, api, endpoint],” that kind of thing. No surprises, no black box.

We improved Browse at the same time: every node in the repository tree got a checkbox, so you can enable a skill straight from the tree without round-tripping through Manage. Skill packages and standalone rules are treated separately, so enabling a package doesn't accidentally toggle individual files inside it.

The Manage tab. Toggling a skill writes the whole package under .cursor/skills/<name>/. The SKILL.md on the right is what feeds the recommender: triggers.dependencies, triggers.files, triggers.keywords.

Then we let an LLM rank them

Heuristic matching is great until the catalog gets opinionated and your repo gets messy. So the Recommended tab now tries an LLM first and only falls back to keyword matching if no model is available. The chain in this exact order is:

1. vscode.lm: VS Code’s Language Model API. If you have GitHub Copilot installed in VS Code, this is already wired up. (Heads up: Cursor doesn’t expose its built-in models through vscode.lm yet, so Cursor users land on step 2 or further.)

2. Cursor SDK: if you’ve set a key.

3. OpenAI: if you’ve set a key.

4. Anthropic: if you’ve set a key.

5. Heuristic: the original signal-matching logic. We label the result with a HEURISTIC badge so you’re never wondering which mode you’re in.

Keys are optional and stored in VS Code Secret Storage, not your settings.json. Set them with Skill Sync: Set OpenAI Recommendation Key (and friends), nuke them with Clear Recommendation API Keys. We don’t see them, we don’t want them.

Results are cached per-workspace with a TTL so the panel doesn’t hit a model every time you blink. Hit Refresh to bypass the cache when something obviously changed.

Ask the Agent: keep the smart part inside Cursor

Now the part Cursor users will care about most.

If you don’t want to wire up an API key, you don’t have to. Click Ask the Agent and the extension does three things:

1. Builds a context-rich prompt. Your workspace fingerprint (languages, deps, monorepo flag, AGENTS.md presence), the current synced catalog candidates, and the skills you’ve already enabled.

2. Opens it pre-filled in Cursor’s composer, via Cursor’s own prompt deeplink. You see a Create chat with prompt sheet first: review, then Create Chat. (We also copy the same prompt to your clipboard, just in case.)

3. Routes the request to a bundled subagent, agents/skill-recommender.md, which is shipped with the repo as a Cursor Plugin. Enable the plugin once and the subagent shows up like any other agent.

The result: no API key, no LLM cost, and the model that already lives inside Cursor (the one you’re paying for anyway) does the ranking, with the context that only the extension can collect.

Recommended on the left, Ask the Agent on the right. The prompt isn’t a one-liner, it includes the workspace fingerprint and the live catalog so the agent has something to reason about.

A small but important detail: oversized catalogs are automatically trimmed to fit Cursor’s deeplink size budget, so this doesn’t silently break on big skills repos.

A new file you didn’t know you wanted: catalog.json

Whenever you sync or browse, the extension now writes a tiny manifest at:

.cursor/skill-sync/catalog.json

Metadata only, no skill bodies. It’s the file the bundled subagent (and any tooling you build on top) reads to know what’s actually in your team catalog right now. If you’ve ever wanted “the agent should know which skills are available without me copy-pasting,” this is that.

The plugin layout follows the official Cursor plugin spec: manifest at .cursor-plugin/plugin.json, agent files in agents/ next to it. Two paths, because that's what Cursor requires, not because we like extra folders.

How to try it (the short path)

1. Install Agent Skill Sync (currently 0.7.0) from Open VSX, or the VS Code Marketplace.

2. Connect a skills repo (owner/repo): yours, your team’s, or play with a public one.

3. Open the Skills sidebar (Ctrl+Alt+S / Cmd+Alt+S) and click the Recommended tab.

4. Either:

   • Don’t configure anything → you get heuristic ranking (badge says HEURISTIC), or

   • Hit Ask the Agent → Cursor’s composer opens with the prompt prefilled, no key needed (works best with the bundled skill-recommender plugin enabled), or

   • Set a provider key via Skill Sync: Set … Recommendation Key → ranking goes live with that model on every refresh.

Toggle what looks useful. Files land under .cursor/rules and .cursor/skills like before. Done.

Why this matters more than “a new tab”

Curated skill repositories are starting to look a lot like internal package registries: versioned, reviewed, owned by the platform team. The next problem after “how do I get them into the editor” has always been: which ones, for this codebase, today?

We don’t think the answer is a longer onboarding doc. The answer is the editor noticing what you’re working on and saying so. The first cut of that is the dumb-but-honest version: signal matching with reason chips. The second cut hands the same context to a model, and if no model’s around, to your own Cursor agent in one click.

If something’s weird, open an issue. If it just works, enable a skill nobody on the team has tried yet and tell us if the ranking was right.

Keska Labs

At Keska Labs, we're betting on a different layer of the stack.

Routing every minor user request through a giant cloud model isn't strategy. It's overhead. The shift that actually matters in 2026 is happening on the laptop on your desk and the phone in your pocket: small, capable models running locally, fast enough to feel instant and cheap enough to feel free.

We believe the future belongs to Small Language Models (SLMs) and Tiny Language Models (TLMs). Here is why we are betting on small, and why it changes the math for everything we build.

Small Models Got Quietly Great

A couple of years ago, a 3-billion-parameter model was mostly a toy. It would lose context quickly and struggle to follow basic logical instructions.

That stopped being true. Carefully filtered training data, distillation from larger teacher models, and architectural improvements have turned sub-10-billion-parameter models into serious production tools.

The current lineup tells the story. Microsoft's Phi-4-mini (3.8B) matches 8B-class models on math and reasoning benchmarks². Google's Gemma 3 (4B) is competitive with last year's 27B flagship and ships with vision and 128K context³. Alibaba's Qwen3 (8B) lets you toggle between fast inference and a slower "thinking" mode for harder problems. Meta's Llama 3.2 (3B) is the open-weight default for mobile.

These models are not trying to be omniscient. Long-tail factual recall is genuinely weak. What they are excellent at is the work most software actually needs: structured output, instruction-following, classification, extraction, and bounded reasoning within a known domain.

Add modern quantization, which compresses a model's memory footprint with only modest loss in quality on these workloads, and an 8-billion-parameter model fits comfortably in around 4.5GB of RAM.

The Hardware Math: Why Now?

There is a lingering assumption that local AI requires a water-cooled, custom-built workstation with expensive GPUs. That stopped being true sometime in 2024, and by 2026 the math has flipped: a meaningful share of the devices already in people's hands can run a useful model locally, today.

The shift was driven by silicon. Apple's Neural Engine, Qualcomm's Hexagon NPU, Intel and AMD's NPUs in Copilot+ PCs, and the unified-memory architecture across Apple Silicon all moved the baseline at the same time. The result is two clear tiers worth thinking about.

The 2B Threshold (~2GB Active RAM): A fast, quantized 2-billion-parameter model fits in roughly 2GB of working memory. That covers every iPhone 15 Pro and iPhone 16 series device, plus the Pixel 8 Pro and up, plus most Snapdragon 8 Gen 3 and Gen 5 Android flagships. Apple alone reports more than 2.5 billion active devices in its installed base⁴; the share of those running on hardware capable of on-device AI grows every quarter as the replacement cycle plays out.

The 4B Sweet Spot (~3.5GB to 4GB Active RAM): This is the target for professional workflows on a laptop, and it requires roughly 16GB of total system memory to leave headroom for the OS, the browser, and everything else a knowledge worker actually has open. As of the March 2026 refresh, every MacBook ships with at least 16GB. AI PCs, which include a dedicated NPU, are forecasted⁵ to make up 55% of all PC shipments in 2026, up from 31% in 2025. Between the two, a substantial and rapidly growing share of the professional installed base can run a 4B model locally without sending it anywhere.

Local first is not a theoretical "five year demographic bet" from now.

What Local Actual Buys You

Take a workload we at Keska Labs focused on: lowering the cost of Knowledge Graph construction. Extracting entities and relationships from large volumes of data and keeping it up to date, simply did not make sense. With 350 million parameters Liquid AI models this is rapidly becoming reality

This is exactly the kind of work where the cloud-first instinct is wrong. Not because frontier models are bad at it (they are very good), but because the workload is repetitive, structured, and high-volume, and routing every record through a cloud API gives up three things at once.

1. No network latency. The data is already on the device that produced it. Removing the round-trip turns extraction from a request-response operation into something that feels like local file processing. No spinners, no rate limits, no degraded behavior on a flaky connection.

2. Compliance by default. For regulated workloads (sensitive complaints, proprietary code, health data, anything covered by GDPR data-residency rules) the data never leaves the device, which collapses a meaningful share of the compliance surface. Local inference is not the whole answer to privacy, but it removes the largest exfiltration vector by construction.

3. Costs that stop scaling with usage. Inference happens on hardware the user already owns and powers. The marginal cost of the millionth extraction is the same as the first: roughly nothing. You still pay for fine-tuning, evaluation, and model distribution, but the per-request cloud bill that scales linearly with adoption disappears.

None of this comes free. Local deployment trades cloud cost for engineering cost: model evaluation across a long tail of customer hardware, an update pipeline for new model versions, drift management as customer data evolves, and a cloud fallback for the requests that genuinely need a frontier model.

The Next 5 Years: The Local Router

As we look toward 2030, the novelty of typing into a chat interface will fade. It was where most people first met AI. What comes next is the model disappearing into the product, and the competitive layer of software moving with it.

Intelligence will be layered. The device in your hand or on your desk will run a small model that is always available, handling the steady, high-volume work that makes up most software interactions: classifying inputs, parsing structure, drafting replies, fetching context from local files, routing requests. The cloud will still be there, and for the work that genuinely needs it (novel reasoning, broad world knowledge, long-context synthesis) it will remain the right answer. What changes is the default. Cloud-first becomes cloud-when-needed, and the routing decision becomes a deliberate one.

We call this the local router. It is the architecture we expect a meaningful share of serious software to converge on by the end of the decade.

For builders, the implication is concrete. The advantage in the next five years will not belong to the teams routing every request to the cloud out of habit. It will belong to the teams who decide deliberately, request by request, where intelligence should live. That is harder than picking an API. It is also where the leverage is.

That is the bet we are making

¹ Tech AI spending may approach 700BN USD this year

² Microsoft Phi-4-mini Technical Report

³ Gemma 3 Technical Report

⁴ Apple reports first quarter results

⁵ Gartner Says AI PCs Will Represent 31% of Worldwide PC Market by the End of 2025

You can grab it on the Open VSX Registry: KeskaLabsAB / agent-skill-sync.

What it does (without the brochure voice)

You connect a source—usually owner/repo on GitHub. The Skill Manager opens in the sidebar: Manage for what’s on in this workspace, Browse if you want to poke around the tree like a civilized person. There’s also catalog search when you’d rather type “api docs” than click five folders.

Content-wise we support the boring-but-useful stuff:

• Single-file rules (.mdc, .md, etc.) → synced as Cursor-style rules.

• Skill packages—folders with a SKILL.md in the agentskills.io shape → whole directory lands under .cursor/skills/<name>/ when you flip it on.

So your “skills repo” can be a real repo: versioned, reviewed, boring in a good way.

Why we bothered publishing it

Internally we were already curating skills in git—security checklists, PR templates, little opinionated prompts that make agents less chaotic. The missing piece was getting that into the editor without ceremony. We got tired of documenting the manual steps for every new machine and every new teammate.

Publishing it was basically: if we need this, someone else might too—and Open VSX is a fine home for tooling that isn’t married to a single storefront. Same extension, same idea: your skills live in source control; the editor just syncs what you opted into.

How to use it (the short path)

1. Install from Open VSX: agent-skill-sync.

2. Open the Skills view (or run the command palette entry for managing skills—your muscle memory may vary).

3. Sign in to GitHub if the repo is private; we use the normal provider flow, nothing exotic.

4. Point it at your repo (owner/repo) or switch to registry mode if that’s your setup.

5. On Manage, toggle what you want. Sync runs in the background or when you hit refresh—either way, files show up under .cursor/rules and .cursor/skills in the workspace you’re in.

Keyboard shortcut people: Ctrl+Alt+S (Windows/Linux) or Cmd+Alt+S (macOS) focuses the sidebar, unless you’ve remapped it to something weirder. We don’t judge.

Settings are the usual skillSync.* keys—source mode, repo string, registry URL, categories, opted-in list. If you live in JSON settings, you already know where to click.

Fine print, but make it fashion

GitHub traffic uses your session. We’re not shipping analytics in the extension to tell you how often you toggled “API documentation.” Skills land in your workspace paths; nothing magic happens in our cloud because there isn’t one for this.

If something breaks, open an issue on github.com/keska-labs/enterprise-skills. If it doesn’t break, enjoy the part where your agent actually reads the same files as the rest of the team.

— Keska Labs