Hermes Wiki
TechResearch/ResearchAgentSkillsSetup/research_agent_skills_setup

Research: Agent Skills — Creating, Enabling & Distributing SKILL.md Capabilities

Deep Research Report | Tech Innovation Tracker (Mode 2) | July 2026

1. 🧭 TL;DR

Agent Skills are the open standard for packaging reusable, procedural knowledge for AI agents. A Skill is nothing more than a folder with a SKILL.md file (YAML frontmatter + Markdown instructions), optionally bundled with scripts/, references/, and assets/. The format was created by Anthropic for Claude Code, then published as an open, vendor-neutral specification at agentskills.io in late 2025. It has since been adopted by 70+ agent products — Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode, Goose, and more.

The core mechanism that makes Skills cheap at scale is progressive disclosure: agents load only name + description (~100 tokens) at startup for every installed Skill, and only pull the full SKILL.md body (and any referenced files) into context when a task actually matches. This is directly relevant to your Knowledge Harness / Hermes architecture — it's the same "load only what's needed" principle you're already applying to procedural memory.

For you specifically: there are now three separate ecosystems worth distinguishing —

  1. Anthropic's native Skills (Claude Code, claude.ai, Claude API) — filesystem-based, first-party.
  2. The open agentskills.io spec — the portable format underlying all of the above, now cross-agent.
  3. Third-party distribution tooling — vercel-labs/skills (the npx skills CLI) and directories like officialskills.sh, which let you install/manage Skills across any of the 70+ supported agents from one command line, not just Claude.

2. 🔍 What It Is — Core Concept

Problem it solves: LLM agents are broadly capable but lack durable, task-specific procedural context. Historically you'd either (a) re-paste the same instructions into every conversation, (b) bloat the system prompt with everything upfront, or (c) build a bespoke tool/fine-tune per workflow. Skills solve this the same way your Hermes/vault split solves memory: separate what an agent generically knows from how to do this one specific recurring thing, and load the "how" only on demand.

Core mechanism — Progressive Disclosure (3 stages):

Stage What loads Token cost Trigger
Discovery name + description (frontmatter only) ~100 tokens/skill Always, at session start
Activation Full SKILL.md body <5,000 tokens (recommended) When a request matches the description
Execution scripts/, references/, assets/ Effectively unlimited Only when explicitly referenced/run

Mental model: A Skill is an onboarding doc you'd hand a new hire — a short cover sheet (frontmatter) that says "here's what I do and when to call me," a body that's the actual playbook, and an appendix of scripts/reference material you'd only flip to if the task demanded it. The agent is the new hire; it doesn't memorize the appendix, it just knows where to look.

This is architecturally the same discretization bet you flagged from the Forge/TMLR synthesis — compress the interface (metadata) so it's cheap to hold many of them in context, and defer the expensive payload (instructions/code) until it's structurally justified by the task.

3. ⚙️ How It Works — Technical Depth

3.1 File structure

my-skill/
├── SKILL.md          # Required: YAML frontmatter + Markdown instructions
├── scripts/           # Optional: executable code (Python, Bash, JS — agent-dependent)
├── references/         # Optional: docs the agent reads on demand (keep 1 level deep)
└── assets/             # Optional: templates, sample files, static resources

3.2 SKILL.md frontmatter spec (agentskills.io)

---
name: pdf-processing
description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
license: Apache-2.0
metadata:
  author: example-org
  version: "1.0"
---
Field Required Constraints
name Yes ≤64 chars; lowercase letters, numbers, hyphens only; no leading/trailing/consecutive hyphens; must match the parent folder name
description Yes ≤1024 chars; must state both what it does and when to use it; no XML angle brackets </> (injection risk)
license, metadata.* No Freely extensible — spec-compliant runtimes ignore unrecognized keys

Claude-specific constraints (platform.claude.com) — slightly stricter than the open spec:

  • name cannot contain the reserved words "anthropic" or "claude".
  • Neither field may contain XML tags.

Design decision worth noting for your Agent Spec template: the reason the format is minimal (two required fields, everything else optional) is portability — any spec-compliant runtime can ignore fields it doesn't understand, so a Skill written for Claude Code loads cleanly in Codex or Cursor without modification, provided you avoid platform-specific features (see §4).

3.3 The Claude-specific execution model

This is the part that differs materially from a "generic prompt template," and matters for your harness thinking:

  1. Claude's environment is a VM with filesystem + bash access. Skills are literal directories on that VM.
  2. When triggered, Claude runs bash: read my-skill/SKILL.md — the instructions enter context via a tool call, not via pre-injection.
  3. If SKILL.md references FORMS.md or a script, Claude reads/executes those only if the task needs them — via further bash calls.
  4. Scripts never enter context. Claude runs scripts/validate.py via bash and receives only stdout/stderr. This is the load-bearing efficiency point: deterministic code stays deterministic and cheap, while the LLM only "sees" the result — directly mirroring your harness-over-model principle (push correctness into code, not into token generation).

3.4 Limitations & tradeoffs

  • Under 500 lines / <5k tokens recommended for the main SKILL.md — anything longer should be split into references/, since the whole body loads atomically once triggered (no partial-loading of a single file).
  • One level of reference nesting only — SKILL.md → references/x.md is fine; references/x.md → references/y.md is discouraged, because progressive disclosure degrades if agents have to chain-follow links.
  • Not portable by default across all features — allowed-tools, context: fork, and hooks are Claude Code–specific extensions not universally supported (see comparison table in §4).
  • Description quality is the actual bottleneck. Multiple independent sources converge on the same finding: skills fail to trigger not because of bad instructions but because of vague descriptions. The description is effectively a routing/retrieval signal, not documentation — treat it like you'd treat an embedding-search query, not a doc header.

3.5 Minimal working example

---
name: readme-writer
description: Creates and writes professional README.md files for software projects. Use when the user asks for a README, project documentation, or repo overview.
---

# README Writer

## When to Use
Trigger when the user asks to create, write, or update a README.md.

## Instructions
1. Inspect the repo structure (list top-level dirs, package manifest).
2. Draft: Title, one-line description, install steps, usage example, license.
3. Write the file to the repo root.

## Examples
See `references/example-readme.md` for a fully worked template.

4. 🆚 Comparison & Landscape

4.1 Anthropic-native surfaces vs. the open standard

Surface Skill types Storage Sharing scope
Claude Code Custom Skills only .claude/skills/ (project) or ~/.claude/skills/ (personal) — pure filesystem Personal, project (git-committed), or via Claude Code Plugins
claude.ai Pre-built (pptx/xlsx/docx/pdf) + Custom Uploaded as .zip via Settings → Features Per-user only — not shared org-wide, no admin/central management
Claude API Pre-built + Custom Uploaded via /v1/skills endpoint; referenced by skill_id in the container param Workspace-wide — all workspace members see uploaded Skills
Claude Platform on AWS / Microsoft Foundry Same as API Same as API Same as API

Critical gotcha: Skills do not sync across these surfaces. A Skill uploaded to claude.ai is invisible to the API and vice versa; Claude Code Skills are filesystem-only and separate from both. If you want the same Skill available in Claude Code and claude.ai and the API, you maintain and upload it three times, independently.

4.2 The open ecosystem — three distinct pieces of tooling

Tool What it actually is Role
agentskills.io The spec itself (originally developed by Anthropic, now open-governed at github.com/agentskills/agentskills) Defines the portable SKILL.md contract every agent below reads
vercel-labs/skills (npx skills) An installer/package-manager CLI — think npm for Skills Adds/removes/updates Skills across 70 supported agents (Claude Code, Cursor, Codex, OpenCode, Gemini CLI, Goose, Copilot, etc.) from one command, with symlink or copy install modes
officialskills.sh A curated directory/marketplace of official (vendor-published) Skills, maintained by the VoltAgent team Discovery layer — "no AI-generated filler," lists Anthropic's own skills (e.g. skill-creator, mcp-builder) alongside vetted third-party ones

Feature-parity gaps across agents (from vercel-labs/skills compatibility matrix):

Feature OpenCode Claude Code Cursor Copilot Others
Basic Skills (SKILL.md) ✅ ✅ ✅ ✅ ✅ (universal)
allowed-tools frontmatter ✅ ✅ ✅ ✅ Mostly ✅
context: fork ❌ ✅ ❌ ❌ Claude Code–only
Hooks ❌ ✅ ❌ ❌ Claude Code, Cline, Kiro CLI only

Positioning verdict: Skills are an additive, protocol-layer standard — not a replacement for MCP or tool-use. They solve a different problem: MCP/tools give an agent capabilities (things it can call); Skills give it procedural knowledge (how and when to use what it already has, plus deterministic scripts it can run directly). This is directly analogous to your "standardize the seam, hot-swap the implementation" principle — Skills are becoming a second seam alongside MCP and A2A in the agent protocol stack.

4.3 Direct alternatives / adjacent approaches

  • Custom system-prompt sections — the pre-standard approach; doesn't scale past a handful of workflows, no progressive disclosure, blows the context budget.
  • RAG over a docs corpus — good for facts, poor for procedures with branching logic and executable steps; Skills are prescriptive, RAG is retrieval.
  • Fine-tuning — solves a different problem (behavior baked into weights); expensive, not auditable, not hot-swappable. Fails your deterministic-first / harness-over-model bar outright.
  • MCP servers — expose tools; Skills expose know-how. They compose: a Skill's instructions can tell an agent which MCP tool to call and in what sequence.

5. 🌐 Perspective — Hosting Skills as a Remote Service (Skills over MCP)

This is a genuinely different architecture from everything in §4, and worth separating out: instead of copying SKILL.md folders onto every machine that needs them, you run one Skills server and let any MCP-compatible agent — yours or someone else's — discover and pull skills from it over the network. This is exactly the pattern your "VPS-hosted MCP server on Hetzner" horizon item is aiming at, just applied to Skills specifically instead of only FlashRank/Hermes.

5.1 Why this is a distinct pattern, not just "MCP as usual"

MCP servers normally expose tools (things the agent can call). Skills-over-MCP instead exposes Skills as MCP Resources — read-only, hierarchical content the agent fetches on demand. The mental shift: a tool is a verb ("do this"); a Skill-as-resource is a document ("here's how"). Both travel over the same MCP connection, but they solve different problems, and — per your own framing to me — tools genuinely are the second priority here; the resource-based Skill catalog is the primitive that matters.

5.2 The protocol-level effort already underway

This isn't just community tooling — Anthropic's own MCP standards body has a working group actively formalizing this: the Skills Over MCP Working Group, building on proposal SEP-2640 (Skills Extension, Extensions Track). The design:

  • Each Skill is served as a set of skill:// URIs — e.g. skill://pdf-processing/SKILL.md, skill://pdf-processing/scripts/extract.py.
  • A server can expose one Skill or hundreds; a well-known catalog resource lets a host read lightweight name+description metadata for all of them up front — this is progressive disclosure, just running over the wire instead of over a local filesystem.
  • Deliberately not a new MCP primitive — it reuses the existing Resources primitive, so any MCP client that already implements Resources gets Skills support close to free. (Adoption gap: many clients don't fully implement Resources yet — this is the open risk.)
  • Ships as an MCP extension, meaning a server can bundle "the tool" (via MCP tools) and "the manual for the tool" (via the Skill resource) together — the working group's own framing is "ship the manual with the product." Directly relevant to your Tool-Fleet Doctor idea: a fleet-observability MCP server that also ships its own usage Skill would demonstrate the pattern you'd be auditing for in other people's servers.
  • Open problem the WG has already surfaced empirically: models frequently try calling tools directly and ignore an available Skill, even when told about it in server instructions — adherence degrades further as context fills up. This is a live reliability gap, not a solved one; worth tracking before you depend on it for anything audit-critical.
  • Open governance question the WG is still working through, relevant to your Compliance platform: should a host trust a Skill from an MCP server automatically? Should enterprise admins be able to approve/block/pin specific skills, the way you'd already want for FINTRAC/OSFI-relevant content? Their example is exactly your shape of problem — a vendor's generic Skill vs. your own internal policy-specific Skill for the same task, and which one should win.

5.3 Working implementations today (pre-standardization)

Several projects already implement "Skills as an MCP server" ahead of the formal spec landing — useful as reference architectures, not necessarily as things to depend on long-term:

Project Approach Notable detail
FastMCP SkillsProvider (Python) Point it at a directory (e.g. ~/.claude/skills); it auto-exposes every valid skill subfolder as MCP resources Cleanest reference implementation if you're building your own server in Python — this is what a Hetzner-hosted "Hermes Skills Server" would most naturally be built on
agentskills-mcp (zouyingcao) Implements the 4-tool pattern explicitly: load_skill_metadata_op (always), load_skill_op (on trigger), read_reference_file_op (on demand), run_shell_command_op (execution) Supports both stdio (local) and SSE/HTTP (mcp.transport=sse, remote) — this is the direct answer to "host it somewhere and let others use it"
agent-skills-mcp (DiscreteTom, Rust) Two modes: system_prompt (skill info folded into MCP server instructions) or tool (skills registered as callable tools) — tool mode exists specifically because many agents ignore MCP server instructions Illustrates the adherence problem from §5.2 concretely — this is a workaround, not a fix
skillport CLI + MCP server; supports categorized skill sets (e.g. one MCP endpoint scoped to development,testing, another to writing,research) via SKILLPORT_ENABLED_CATEGORIES Closest to a real access-control primitive — relevant to your boundary-router thinking (local-only vs. public-eligible categories, mapped to separate MCP endpoints)
Microsoft Foundry "Skills REST API" (preview) Enterprise-grade version of the same idea: author SKILL.md once, store centrally, load into any hosted agent container via API Shows what this looks like once a vendor productizes it — a preview of where the OSS tools above are heading

5.4 What this buys you concretely, mapped to your architecture

  • A single source of truth. Instead of npx skills copying files to N machines, one Hetzner-hosted server is the canonical Skill store; every agent (your laptop's Claude Code, a teammate's Cursor, a future hosted agent) pulls the same version live. This directly resolves the "no cross-surface sync" gotcha flagged in §4.1 — the sync problem disappears if nothing is copied in the first place.
  • Skills become a Localz/Compliance product surface, not just a personal productivity trick. A hosted Skills-over-MCP endpoint is a legitimate "callable connector" in the same category as the FlashRank/Hermes exposure you already planned — e.g., a "Compliance Reasoning Skill Server" that any client agent (yours or a customer's) can point at, with the actual regulatory-prose instructions never leaving your infrastructure.
  • Access control is now a server-side concern, which is a better fit for your Trust & Governance instincts than filesystem permissions ever were — you can categorize, version, gate, and audit which Skills are servable to which caller, exactly the shape of control the WG itself is still debating for the ecosystem at large.
  • This is genuinely pre-1.0. SEP-2640 is a working draft, adoption in mainstream MCP clients is not yet universal, and the model-adherence problem (§5.2) is unresolved. Good rung-5/rung-6-style validation target for the A2A Ladder methodology — build it now on agentskills-mcp or FastMCP's provider as a working prototype, but don't put it on the critical path for anything regulated until the spec and client support mature.

6. 💻 Perspective — Skills Inside IDEs (Claude Code, Cursor, Windsurf, VS Code/Copilot)

The second angle you raised — using Skills (with or without MCP) inside the IDE you're actually coding in — is where the format is furthest along in practice, but with real fragmentation underneath the shared file format.

6.1 Directory conventions differ; the file format doesn't

IDE / Tool Skills directory Global (personal) skills? Always-on context file Agent engine
Claude Code .claude/skills/ (project) + ~/.claude/skills/ (personal) ✅ Yes CLAUDE.md Native CLI agent
Cursor .cursor/skills/ (project only) ❌ No .cursorrules / .cursor/rules/*.mdc Composer
Windsurf .windsurf/skills/ (project only) ❌ No .windsurfrules Cascade
VS Code + GitHub Copilot Via Copilot Extensions / instructions files (no native SKILL.md folder convention as of mid-2026) ❌ No copilot-instructions.md Copilot Agent mode

The load-bearing fact: the same SKILL.md file — frontmatter and body — works unmodified in Claude Code, Cursor, and Windsurf. What differs is (a) where you put the folder and (b) which extra frontmatter fields get honored. Claude Code–specific fields like context: fork and hooks are silently ignored by Windsurf and Cursor rather than causing errors — this is intentional per the open-spec design (§3.2): unrecognized keys are ignored, not rejected, which is exactly what makes cross-agent portability work.

6.2 The practical fragmentation problem

Because global/personal skills only exist in Claude Code, Cursor and Windsurf users must copy the same Skill into every project's local skills/ folder — there's no personal library equivalent. This is a real point of friction if you code across FullStackFusions, Localz, and Compliance repos in the same IDE and want one shared "commit message style" or "API error-handling pattern" Skill everywhere: in Claude Code it's one file in ~/.claude/skills/; in Cursor or Windsurf you're maintaining N copies (or a symlink/sync script) across N project repos.

This is precisely the gap npx skills and skillport (§4.2, §5.3) exist to close — both explicitly support "install to Cursor, Windsurf, Copilot, and any MCP client from one source," which is the practical answer to fragmentation rather than a spec-level fix. Given you already use uvx-style installers for other tools in your stack (the Agent Skills standard note in your own tooling — uvx library-skills --claude), skillport's uv tool install skillport / skillport add workflow would slot into an identical mental model.

6.3 Skills vs. "always-on rules" files — a design decision, not a preference

Every IDE in this table has two distinct context mechanisms, and conflating them is the most common practical mistake:

  • CLAUDE.md / .cursorrules / .windsurfrules / copilot-instructions.md — loaded on every interaction, always in context. Correct for stack-wide facts: "we use FastAPI + pgvector," "always run pip install --break-system-packages."
  • SKILL.md in a skills folder — loaded only when the task matches the description. Correct for a specific, bounded procedure: "how to add a new Alembic migration," "how to run the FlashRank benchmark harness."

Putting a bounded procedure in the always-on file wastes context budget on every single turn; putting stack-wide facts in a Skill means they're invisible unless the description happens to match. This maps directly onto your declarative-vs-procedural memory boundary discipline — the always-on file is closer to your Obsidian vault's role (durable, general, always relevant), the Skill folder is closer to Hermes's role (specific, bounded, loaded on demand). Worth treating IDE skill folders as literally an instance of the same boundary you've already designed, not a separate concept to learn.

6.4 Claude Code specifically: the two paths converge

Because Claude Code supports both native filesystem Skills and MCP, it's the one IDE where §5 and §6 meet directly: you can either drop a SKILL.md into ~/.claude/skills/, or connect Claude Code to a remote Skills-over-MCP server (claude mcp add skillport -- uvx skillport-mcp, or your own Hetzner-hosted agentskills-mcp instance) and get the same skills without local files at all. For a team where you're the only Claude Code power-user today but may onboard collaborators onto Cursor or Windsurf later, starting with a hosted MCP Skills server rather than a personal ~/.claude/skills/ folder is the more future-proof choice — it's the one architecture that serves all four IDEs in the table above from a single canonical source, sidestepping the fragmentation in §6.2 entirely.

7. 🔗 Relevance to Your Stack

Hermes (procedural memory layer): This is the closest conceptual sibling to what you've already built. Skills are essentially a standardized, filesystem-native serialization format for exactly the "how-to" knowledge Hermes is designed to hold. Worth an explicit design question: should Hermes emit SKILL.md-compatible files as one of its output formats, so procedural knowledge learned/accumulated in Hermes becomes directly loadable by any Claude Code session (or any of the 70 agents npx skills supports) without a bespoke integration layer? That would make Hermes a Skill factory, not just an ambient agent.

Knowledge Harness / Synto wiki: The three-tier loading model (metadata → instructions → resources) in Skills is a near-exact match for the declarative/procedural/episodic tiering you've already designed. Your boundary router (local-only vs. public-eligible) maps cleanly onto the Claude API's workspace-wide sharing vs. Claude Code's filesystem-personal/project split — you already have the access-control primitive; Skills just gives it a standard file format to enforce against.

A2A Offload Mesh / Agent Stack Radar: Skills sit at the same protocol layer you've been mapping (MCP, A2A, Skills) as the three legs of the agent interoperability stack. For the Radar, Skills likely belongs in a "Standardize" or "Trial" ring given: (a) it's genuinely open-governed now (not Anthropic-proprietary), (b) 70-agent adoption is real breadth, but (c) feature parity is uneven (hooks/context:fork are Claude Code exclusives) and cross-surface sync inside Anthropic's own products is not solved — a real gap for anything you'd call production-grade multi-surface deployment.

Compliance/GRC AI — evidence-gated discovery process: The Claude docs' own security section is directly usable as a starting checklist for your evidence bar: audit every bundled file (SKILL.md, scripts, assets) for unexpected network calls or file-access patterns before trusting a third-party Skill; treat Skills from unknown sources like installing unreviewed software. Given your "no vibe-coded tools in regulated contexts" rule, officialskills.sh's "official, vendor-published only" curation model is a better sourcing policy for anything touching the Compliance platform than the broader (and much larger) skills.sh community index, which includes unaudited community submissions.

FullStackFusions (unresolved): There's a clean, empirically-flavored Part 7 or spin-off post here: "I benchmarked SKILL.md description quality vs. trigger accuracy" — several sources (Agentman, Medium) converge on "if a skill doesn't trigger, it's the description, not the instructions" as received wisdom, but none of them show measured trigger-rate data. That's a gap matching your brand (real numbers replace placeholders).

8. 🚀 How to Get Started

Path A — Claude Code (most relevant to your current environment)

# Create the skeleton
mkdir -p ~/.claude/skills/my-skill/{scripts,references,assets}
cd ~/.claude/skills/my-skill

Write SKILL.md with name + description frontmatter (template above). Claude Code discovers it automatically — no registration step. Use ~/.claude/skills/ for personal/global use, .claude/skills/ inside a repo for project/team-shared (git-committed) use.

Fastest bootstrap — use Anthropic's own skill-creator skill (found via officialskills.sh), which guides you through drafting, running before/after test cases, and iterating on the description until trigger accuracy is acceptable:

npx skills add https://github.com/anthropics/skills --skill skill-creator

Path B — Cross-agent install via the open CLI

If you want a Skill available across Claude Code and other agents you use (OpenCode, Cursor, Gemini CLI, etc.) from a single source of truth:

# Install a skill repo to all detected agents
npx skills add vercel-labs/agent-skills --all

# Install one specific skill to specific agents
npx skills add vercel-labs/agent-skills --skill frontend-design -a claude-code -a opencode

# Scaffold a new skill
npx skills init my-skill

Default install mode is symlink (single canonical copy, all agents point to it — easiest to update); use --copy only if the target agent doesn't support symlinks.

Path C — claude.ai (personal, non-technical use)

Settings → Features → upload a .zip containing your SKILL.md (+ optional subfolders). Requires Pro/Max/Team/Enterprise with code execution enabled. Remember: this is per-user, not synced to Claude Code or the API — you'd re-upload separately if you want the same Skill there.

Path D — Claude API (for anything you productize, e.g. Localz or Compliance agent backends)

Requires three beta headers: code-execution-2025-08-25, skills-2025-10-02, files-api-2025-04-14. Upload custom Skills via /v1/skills; reference by skill_id in the container parameter alongside the code-execution tool. Uploaded Skills are workspace-wide — relevant if Localz or the Compliance platform later needs a shared, versioned Skill library across a team rather than per-developer filesystem copies.

First thing to try

Write one Skill for a workflow you already repeat by hand across sessions — e.g., "Localz listing QA checklist" or "Compliance report formatting" — deliberately keep it under 5k tokens, and test whether Claude reaches for it unprompted on a naturally-phrased request. If it doesn't trigger, rewrite the description before touching the instructions (per the trigger-accuracy finding in §3.4).

Validate before trusting

# skills-ref reference library validates frontmatter + naming conventions

(referenced in the agentskills.io spec — check current install instructions in the repo before adding to a CI/lint step for your own Skills library.)

9. 📎 References & Links

🗂️ Quick Reference Index

[Concept] Progressive Disclosure — 3-stage loading (metadata → instructions → resources) that keeps many skills cheap in context
[Spec]    agentskills.io — open, vendor-neutral SKILL.md format spec, originated by Anthropic, now community-governed
[Tool]    npx skills (vercel-labs/skills) — CLI to install/manage Skills across 70+ agents from one source of truth
[Tool]    skill-creator (Anthropic) — official skill for drafting, testing, and iterating on new Skills
[Resource] officialskills.sh — curated directory of vendor-published (not community) Skills
[Concept] Skill sharing scope — claude.ai (per-user), Claude API (workspace-wide), Claude Code (filesystem: personal/project)
[Constraint] No cross-surface sync — a Skill uploaded to claude.ai, API, and Claude Code must be maintained 3x separately
[Concept] Skill vs MCP vs A2A — Skills = procedural know-how; MCP = tool access; A2A = agent-to-agent delegation; complementary, not competing
[Concept] Skills over MCP (SEP-2640) — serving Skills as MCP Resources via skill:// URIs; formal WG-driven proposal, not yet finalized
[Risk]    Model tool-preference bug — agents often call tools directly and skip an available Skill even when told to check it first; unresolved in the WG's own testing
[Tool]    FastMCP SkillsProvider — Python library that turns a local skills directory into a full MCP resource server in ~3 lines
[Tool]    agentskills-mcp / skillport — working remote-hosting implementations for Skills-over-MCP, pre-dating the formal spec
[Concept] Skills fragmentation across IDEs — only Claude Code has a personal/global skills folder; Cursor and Windsurf are project-scoped only, so a hosted MCP server is the only single-source-of-truth option across all three
[Concept] Rules file vs Skill file — CLAUDE.md/.cursorrules/.windsurfrules = always-on context; SKILL.md = loaded only on task match; mirrors your declarative-vault vs procedural-Hermes boundary directly
  • hermes-harness-spec — the vault's own harness/agent architecture; FIX-AGENT (§2 addition, 2026-07-04) is the first concrete instance of "Hermes emits SKILL.md" this research asks about in §7
  • agent_harness_hands_on — harness-over-model principle this research draws the direct parallel to in §3.3
  • harness-rtk-headroom-synthesis — same "push correctness into deterministic code, not token generation" thesis this note applies to Skills' script-execution model
Hermes Wiki