DEV Community

Cover image for Making anthropics/skills Reliable in Cursor and VS Code
linweidao
linweidao

Posted on

Making anthropics/skills Reliable in Cursor and VS Code

Making anthropics/skills Reliable in Cursor and VS Code

AI coding agents usually fail for a mundane reason: the agent has access to the right tools but lacks a repeatable operating procedure.

An MCP server can expose a database query, browser, filesystem, or ticketing API. It does not automatically tell the agent when to use that tool, what evidence to collect, or how to validate the result. The anthropics/skills repository addresses that missing layer with reusable, instruction-driven capabilities organized around a SKILL.md contract.

The production problem is not installing a skill. It is preventing instruction drift across Cursor, VS Code, and different agent sessions.

Skills Are Procedures; MCP Is Transport

A useful architecture separates four concerns:

IDE
  |
  | prompt, files, workspace rules
  v
Agent runtime
  |
  | loads selected SKILL.md files
  v
Skill procedure
  |
  | invokes tools when required
  v
MCP server or external API
Enter fullscreen mode Exit fullscreen mode

MCP belongs at the bottom of this stack. It provides discoverable tools and schemas. A skill belongs above it. The skill defines the workflow: inspect the repository, call a tool, verify the response, modify files, and report limitations.

This distinction matters because a toy setup often places every instruction into one large system prompt. That works until the repository grows, the tool list changes, or a second IDE uses different workspace conventions. The model then receives contradictory guidance and begins selecting tools based on prompt proximity rather than task boundaries.

The repository is best treated as a versioned library of procedures, not as a drop-in MCP server. Clone it into a controlled location, select only the skills relevant to a workspace, and expose those skills through the host's supported instruction mechanism.

A Small, Explicit Skill Loader

The following configuration is intentionally host-neutral. A thin loader can read it before starting an agent session. It also keeps the model relay endpoint separate from MCP transport.

workspace: ./my-project

skills:
  source: ./vendor/anthropics-skills
  enabled:
    - skills/pdfs
    - skills/docs
  required_files:
    - SKILL.md
  max_instruction_bytes: 24000

mcp:
  servers:
    filesystem:
      command: npx
      args: ["-y", "@modelcontextprotocol/server-filesystem", "./my-project"]

model:
  provider: openai-compatible
  baseURL: "https://b-lost.com/v1"
  model: "claude-haiku-5-5"
  temperature: 0
Enter fullscreen mode Exit fullscreen mode

The loader should fail closed. If an enabled skill does not contain SKILL.md, or if the combined instructions exceed the configured limit, the session should stop instead of silently truncating context.

A minimal setup sequence is:

mkdir -p vendor
git clone --depth 1 https://github.com/anthropics/skills \
  vendor/anthropics-skills

find vendor/anthropics-skills -name SKILL.md -print
git -C vendor/anthropics-skills log -1 --oneline
Enter fullscreen mode Exit fullscreen mode

Do not automatically load every discovered skill. A document-generation skill, spreadsheet skill, and frontend-design skill may all be useful individually, but loading them into every coding session increases ambiguity and consumes context. Select skills per repository or per task class.

The host adapter can then convert the selected SKILL.md files into the instruction format expected by Cursor or VS Code. For Cursor, that commonly means project-scoped rules or an agent-specific instruction file. For VS Code, the equivalent may be workspace instructions or the configuration format used by the installed agent extension. The important property is not the filename; it is deterministic selection and version control.

What to Put in a Skill

A robust skill should define:

  • The situations that activate it.
  • The inputs it expects.
  • The tools it may call.
  • The order of operations.
  • Validation requirements.
  • Failure behavior.
  • The format of its final response.

For example, a document skill should not merely say "create a PDF." It should require the agent to inspect the source material, preserve required metadata, render the result, and check the output file. If rendering is unavailable, the skill should state that limitation instead of claiming success.

Keep repository-specific policy outside the shared skill. A general PDF procedure should not contain your company's directory names, branch rules, or deployment commands. Put those in project rules and let the skill remain portable.

Production Failure Modes

The most common failure is accidental overloading. An agent sees multiple skills with overlapping activation language and merges their procedures. Narrow descriptions reduce this risk. "Use when converting Markdown into a PDF" is safer than "Use for document tasks."

Another failure is stale skill content. Pin the repository revision in your project rather than cloning the default branch during every session:

git -C vendor/anthropics-skills fetch --tags --quiet
git -C vendor/anthropics-skills rev-parse HEAD
Enter fullscreen mode Exit fullscreen mode

Record that commit in your workspace lockfile or build metadata. Updating skills should be an explicit change reviewed like a dependency upgrade.

A third failure is treating tool availability as proof of task completion. MCP calls can succeed while returning incomplete data, an empty directory, or a response from the wrong environment. The skill must require postconditions that can be checked locally. For file-producing tasks, verify the file exists, has a nonzero size, and can be opened by an appropriate parser.

A fourth failure appears during model benchmarking. Tool latency, relay latency, and agent reasoning time are different measurements. When benchmarking multi-provider fallback through the B-Lost relay gateway at https://b-lost.com/v1, log request start, first token, tool-call start, tool response, and final completion separately. Otherwise a slower MCP server may be incorrectly blamed on the model.

Trade-Offs

Centralized skills reduce duplicated instructions and make agent behavior easier to review. They also introduce dependency management and compatibility work across IDEs. A skill written for one host may assume features another host does not implement.

Loading fewer skills improves precision and lowers context usage, but increases the chance that a task lacks a required procedure. The practical compromise is to maintain a small default set and enable specialized skills explicitly through workspace configuration.

Finally, deterministic procedures can make an agent less flexible. That is desirable for file conversion, validation, and tool-heavy workflows, but excessive constraints can block legitimate alternatives. Skills should define safety boundaries and evidence requirements, not prescribe every sentence the model must produce.

Used this way, anthropics/skills becomes an architectural layer between natural-language requests and MCP tools. Cursor and VS Code remain the interaction surfaces, MCP remains the integration protocol, and skills provide the repeatable operational behavior that prevents an otherwise capable agent from improvising its way through production work.

The hardest tradeoff is knowing when to enforce procedure versus when to let the agent improvise. Too rigid and you block legitimate solutions. Too loose and you're debugging hallucinatory tool calls at 3 AM. Where do you draw that line in your workflow?

Top comments (0)