DEV Community: Charles950311

Agent skills are a supply chain risk. Scan them like it matters.

Charles950311 — Sat, 24 Oct 2026 12:40:58 +0000

Agent skills are the new npm packages — except a package's install script is code you can statically analyze, and a SKILL.md is a natural-language program your agent reads and obeys. That difference changes everything about how you should treat them.

The Agent Skills standard went open in December and 70+ platforms now load the same folder format. Marketplaces popped up within weeks. Meanwhile a security-audit skill from a major CDN vendor sat at the top of GitHub trending — the ecosystem is clearly hungry for "skills". What almost nobody is talking about: installing a third-party skill is a supply-chain decision.

What a skill can actually ask for

Strip away the branding and a skill grants its author three channels into your session:

Instructions the model treats as authoritative. The description alone steers when the skill activates. Prompt-injection isn't a hypothetical here — it's the native instruction format.
Tool permissions. allowed-tools lines decide whether the skill may read files, run shell commands, or hit the network during its "workflow steps".
Bundled scripts. Many skills ship helper scripts the agent is told to execute at step N. That's arbitrary code execution with your working directory as the blast radius.

None of this is a flaw in the standard — it's the feature. But it means "try this cool skill I found" is closer to curl | bash than to installing a browser extension.

The pre-install checklist I run now

I run real security-audit pipelines with agent skills daily, and this is the discipline that survived contact with reality:

1. Scan before install. Cisco's open-source skill-scanner catches the low-effort malicious stuff — credential reads, destructive deletes, known injection patterns. No findings ≠ safe, but it clears the floor.

2. Read the SKILL.md like an attacker. Where does it ask the agent to send data? Which URLs? What "verification steps" involve executing bundled binaries? A five-minute read beats a post-incident forensics month.

3. Check allowed-tools against the actual need. A transcription skill does not need shell access. A report formatter does not need network. Scope mismatch is the loudest signal.

4. Keep a provenance manifest. Every install recorded: version, source repo, license, how you verified it. When the next supply-chain incident drops, "was I exposed?" becomes a one-line lookup instead of archaeology.

5. Refuse with reasons, in writing. My manifest records plugins I refused — safety-policy bypasses, third-party account pools. The refusal reasons are knowledge too; they stop you re-litigating the same decision in three months.

The same lens, pointed at your own code

That discipline scales up. Once you treat "what can this input reach?" as the core question, code review becomes a taint walk: entry points → sources → sinks, with an explicit verdict on every sanitizer in between. I packed that method into a skill as well — a taint-analysis code-audit skill with a 0–10 severity rubric and a hard output contract: every finding ships with file:line, the taint path, and the minimal request that proves it. No walkable path means it goes in the hardening appendix, never inflated to a "vulnerability".

It's live as a free tool edition on Swarms Marketplace, and the governance tooling I use to keep my own installs honest is open source: dsh-plugin-hub (routing table, health checks, the provenance manifest itself).

The uncomfortable summary

We spent a decade teaching developers not to curl | bash. Then we built a format whose entire value proposition is "the model will follow these instructions" — and started collecting them from strangers. Skills are worth it. Install them like it matters.

What's your pre-install routine for third-party skills — or are we all still at curl | bash stage? Comments very welcome.

I installed 7 plugins in DeepSeek Harness. Then I built a control hub for them.

Charles950311 — Sat, 24 Oct 2026 12:11:16 +0000

DeepSeek Harness (dsh) went open source in August and blew past 130K stars in
weeks. Its architecture pitch is one line: everything is a plugin — a
deliberately thin core, capabilities arriving as .dsh.bundle plugins and
hot-loaded skills.

That means the ecosystem explodes fast. It also means that at plugin #7 you hit
every plugin platform's classic problem — except this time nobody solved it for
you.

The four pains nobody warns you about

Installing is easy: dsh plugin --profile desktop add <pkg> with HMR mounting
it live. The pain starts after:

Entries are scattered. Turn rewind lives in the Web UI, long-term memory is a hindsight_* tool plus a Python service on port 8888, the failure-experience library speaks MCP, skill cards sit under the input box. Even the agent isn't sure which tool is called what — let alone the user.
Status is uncertain. "Is this plugin usable right now?" A loaded plugin is not a running service. hindsight can load fine while port 8888 is down — and the call fake-succeeds.
Trust needs managing. Dozens of community plugins appeared within weeks. Installing an unknown SKILL.md means wiring a natural-language program into your agent. Did you scan what files it wants to read and what it runs?
Nobody keeps the manifest. What did you install last week, which version, why did you remove it? Two weeks later: gone.

The fix: a hub skill + three disciplines

I built the governance layer itself as a skill: dsh-plugin-hub (open source,
MIT).

One routing table. The SKILL.md is a table: user intent → which tool →
current state. The agent stops guessing from training data and starts looking
things up.

One status command. status.ps1 checks everything in one shot: profile
plugins, tool files on disk, services up/down, where the skill junctions point.
The skill has a hard rule baked in: confirm status before dispatching; if it's
down, say so — never pretend a call succeeded.

One junction trick. All my skills live in one directory (easy to back up and
sync), junctioned into %USERPROFILE%\.dsh\skills so DSH hot-loads them. New
skills never touch .dsh; git manages the unified directory.

One manifest (PROVENANCE). Every install/remove updates a table: version,
source, license, how it was verified. The routing table may only claim what this
file confirms. The table is not allowed to lie — that's the most important
rule of the whole design.

Bugs I hit so you don't have to

Version compatibility: after 0.2.0 → 0.2.1-rc.2, turn-rewind 0.3.9 broke; 0.3.10 + one missing dependency fixed it. Check peer deps before upgrading the harness.
Startup order: hindsight calls an external model API on boot — no egress, instant Application startup failed. Network first, service second.
Some plugins you just don't install: safety-policy-bypass plugins and third-party account pools. Compliance and credential risk are both too high. The manifest records the refusal with the reason — refusals are knowledge too.
Scan before install: Cisco's skill-scanner runs locally. No findings ≠ safe, but it catches the low-effort malicious stuff — then a human reads the scripts.
Windows PowerShell 5.1 parses UTF-8 scripts as ANSI unless they have a BOM. My first "generic" config broke on any non-ASCII path because of this. One byte at the start of the file; hours of confusion saved.

The result

"Remember this" routes to hindsight. "Undo that edit" routes to turn-rewind.
"Can I install this skill?" goes through skill-scanner first. One table owns all
entries, one command owns all status, one manifest owns all trust.

Repo: Charles950311/dsh-plugin-hub (MIT), install.ps1 and you're in. Stars/PRs welcome.
I'm building a skills factory and security-audit pipeline on the same pattern —
follow if that's your kind of thing.