# Reported issues for Agent Skills Search Server

Pod holds 21 of 25 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Agent Skills Search Server](/mcp/agent-skills-search-server).

## Most discussed

### Clarify whether SKILL.md metadata supports arbitrary values or only strings

# Issue: Clarify whether `metadata` supports arbitrary values or only string values

The current Agent Skills specification appears to describe two different constraints for the optional `metadata` field in `SKILL.md` frontmatter.

In the [frontmatter overview table](https://github.com/agentskills/agentskills/blob/38a2ff82958afee88dadf4831509e6f7e9d8ef4e/docs/specification.mdx#L18-L26), `metadata` is described as:

> Arbitrary key-value mapping for additional metadata.

However, the later [`meta

[Read the thread](https://github.com/agentskills/agentskills/issues/474) · 2026-08-01 · closed · external user · 3 comments

### Spec lacks guidance on skill verification and supply-chain trust

Summary
The spec defines how skills are structured and discovered, but it doesn't address how an agent (or a human) decides whether a skill is safe to install and run. As the ecosystem grows, that gap becomes the main risk in the format.
Why this matters
A skill is a folder of instructions and scripts that an agent will load and execute. That is, by design, an execution surface. Two concrete risks follow from the open format:

Malicious or poisoned skills. Anyone can publish a skill. A skill can

[Read the thread](https://github.com/agentskills/agentskills/issues/418) · 2026-06-09 · closed · external user · 6 comments

### Proposal: AgentFile — Declarative Agent Composition from Skills + Filesystem-Native Skill Delivery [Draft]

<html><head></head><body><h2>Summary</h2>
<p>Skills define what agents <em>can do</em>. But there's no standard for how to <strong>assemble skills into a running agent</strong> — or how to make skills accessible to models that can't speak MCP.</p>
<p>This proposal introduces two complementary ideas:</p>
<ol>
<li><strong>AgentFile</strong> — a declarative configuration format (like Dockerfile, but for agents) that composes skills, models, credentials, and runtime behavior into a deployable agent<

[Read the thread](https://github.com/agentskills/agentskills/issues/178) · 2026-02-22 · closed · external user · 4 comments

### Proposal: Agent Actions

## 1. Overview

This proposal introduces `ACTIONS.yaml`—an optional file that enhances skills with runnable, typed tools with execution semantics.

### Motivation

Skills can bundle scripts, but there's no standard way to:
- Define typed inputs and outputs
- Execute scripts without parsing prose instructions
- Inject secrets securely (without exposing them to the LLM)
- Compose actions into pipelines
- Discover specific operations (skills describe broad capabilities; actions expose precise inter

[Read the thread](https://github.com/agentskills/agentskills/issues/87) · 2026-01-14 · closed · external user · 10 comments

### Proposal: support secrets

From my understanding of skills, it standardizes agent filesystem to be able to store custom prompt, markdown files and scripts
It would be helpful to add the possibility to support secrets / API keys

I'm working at a SaaS company, Skills are wonderful but not enough to handle authentication
Basically we would like that our customers upload a skills to their own LLM (chatGPT or Claude), then they can do CRUD on our SaaS with their own permissions
MCP allows this, but are complex to set up

Thin

[Read the thread](https://github.com/agentskills/agentskills/issues/86) · 2026-01-14 · open · external user · 5 comments

### Proposal: Container Execution Fields for Agent Skills

## Summary

This proposal adds optional fields to the Agent Skills specification that enable containerized, portable execution of skills. These fields allow skill authors to define the runtime environment alongside the skill definition, ensuring skills run identically across any machine. This would enable Agent Skills to be imported as MCP tools, execute via CLI, or used as standard skills.

Notes: This is the current setup I'm using for https://enact.tools. If this proposal is rejected I'll lik

[Read the thread](https://github.com/agentskills/agentskills/issues/61) · 2026-01-03 · closed · external user · 3 comments

### Proposal: Progressive disclosure for tools

## Summary

Extend the Skills specification to support progressive disclosure of **tools** by allowing optional YAML frontmatter in reference files (`references/*.md`), not just `SKILL.md` files. 

This enables agents without code execution environments to progressively load tools as instruction files are read.

## Motivation

Skills enable progressive disclosure by deferring content loading until needed. Specifically, content under `./references/` is only read when the LLM determines the additi

[Read the thread](https://github.com/agentskills/agentskills/issues/53) · 2025-12-29 · open · external user · 4 comments

### mcpServers frontmatter spec

Hi, it would be great to include `mcpServers` in the front-matter, so agents can parse and dynamically install servers. We've been using this on some skills in [Smithery](https://smithery.ai/skills)!

`mcpServers` is just a list of Streamable HTTP urls. The agent/client can decide whether or not it wants to install it.

[Read the thread](https://github.com/agentskills/agentskills/issues/21) · 2025-12-20 · open · external user · 7 comments

## Most recent

### Proposal: machine-evaluable 'dependencies' field in frontmatter for tools

# Proposal: machine-evaluable `dependencies` field in frontmatter for tools

## Summary

Add an optional `dependencies` field to `SKILL.md` frontmatter that lets a skill declare, in machine-evaluable form, the tools (and optionally resources/prompts, if relevant) it needs in order to function — with `all` / `any` semantics. This gives hosts a basis for deciding whether a skill should be surfaced or activated at all, rather than discovering a missing prerequisite mid-task.

## Motivation

`descri

[Read the thread](https://github.com/agentskills/agentskills/issues/485) · 2026-08-07 · open · external user · 0 comments

### Showcase: cursor-kenji — 90 validated Cursor agent skills

## Project

**cursor-kenji** — open-source (MIT) collection of 90 Cursor agent skills, 13 slash commands, 5 subagents, and MCP templates for React / Next.js / Supabase.

## Spec compliance

All skills validate against the Agent Skills specification via `npm test` in CI (102 installable skills including Cursor IDE tools).

## Install

```bash
npx skills add kensaurus/cursor-kenji
```

## Links

- GitHub: https://github.com/kensaurus/cursor-kenji
- npm: https://www.npmjs.com/package/@kensaurus/cur

[Read the thread](https://github.com/agentskills/agentskills/issues/432) · 2026-06-23 · closed · external user · 0 comments

### Proposal: Allow skills to declare tool dependencies

## Motivation
There has been a growing need for skills to define dependencies on specific tools (especially with larger adoption of agent plugins). Currently, from the client perspective it can be easy to get into a state where these dependencies are not fully respected and we end up with unexpected errors when using skills. It would be great if we could have a platform-agnostic way to define tool dependencies which can offer a graceful error message and either show a warning message or prompt t

[Read the thread](https://github.com/agentskills/agentskills/issues/330) · 2026-04-21 · closed · external user · 2 comments

### Proposal: `vertical` metadata field for industry-specific skill discoverability

**Problem:**

The current agentskills spec has no way to declare what industry or domain a skill is built for. A regulatory intelligence skill for pharma looks identical to a git automation skill in the directory. As the ecosystem grows beyond developer tooling into business, legal, medical, and financial verticals, discoverability breaks down completely.

**Proposal: `vertical` field in skill frontmatter**

```yaml
---
name: fda-regulatory-brief
description: Weekly FDA clearance and warning let

[Read the thread](https://github.com/agentskills/agentskills/issues/288) · 2026-04-02 · closed · external user · 0 comments

### Proposal: `output-type` metadata field to distinguish raw-retrieval from pre-processed skill outputs

**Problem:**

Skills currently have no way to declare whether their output is raw retrieved data or pre-processed, structured intelligence. This distinction matters significantly for:

- **Token budgeting** — a skill that returns 50KB of raw HTML is a different runtime cost than one that returns 2KB of structured markdown
- **Chaining** — agents composing skills need to know if output requires further processing or is model-ready
- **Quality expectations** — users downloading a skill have no sig

[Read the thread](https://github.com/agentskills/agentskills/issues/287) · 2026-04-02 · closed · external user · 0 comments

### Add required permissions to skill metadata to support least-privilege installation

## Background

At the moment, users cannot clearly see what permissions a skill requires before installing it. This may lead to over-permissioning, which increases security risks and makes it harder for users to apply the principle of least privilege.

## Proposal

Add a structured `required_permissions` field to skill metadata so that each skill can explicitly declare the permissions it needs to function.

This could include permissions such as:

- Commands the skill needs to execute
- Tools or

[Read the thread](https://github.com/agentskills/agentskills/issues/249) · 2026-03-16 · closed · external user · 0 comments

### Proposal - capabilities field for security and transparency

## Problem

Skills are a new class of executable content. When an agent loads a SKILL.md, those instructions can trigger arbitrary tool calls - shell commands, file writes, network requests, browser automation. But the spec has no structured way for a skill to declare what system access it needs, and no way for users or platforms to know what a skill can do before it runs.

This is already being exploited. Snyk's ToxicSkills research found that **13.4% of all skills contain at least one critical

[Read the thread](https://github.com/agentskills/agentskills/issues/170) · 2026-02-18 · closed · external user · 2 comments

### Proposal: Agent Skills SDK - storage-agnostic providers, progressive disclosure tools, and agent framework integrations

## Summary

I've built an open-source Python SDK for integrating Agent Skills into custom LLM agents. It goes beyond the current `skills-ref` reference library by adding storage-agnostic providers, progressive disclosure tools, and agent framework integrations. I'd like to contribute it to this repo.

**Repo:** https://github.com/pratikxpanda/agentskills-sdk

## What it adds

The SDK addresses two gaps not covered by `skills-ref`:

### 1. Storage-agnostic providers
`skills-ref` assumes skills li

[Read the thread](https://github.com/agentskills/agentskills/issues/139) · 2026-02-13 · closed · external user · 1 comment

### Proposal: AgentSecOps-ready “Security Harness” for Agent Skills

## Background / context

As AI agents become more capable, the security model is shifting from “prompt hygiene” toward harnessed execution: systems where tool use, data movement, and side effects are constrained by policy and verified with evidence. In practice, teams are already building multi-layer defenses across:

- Orchestrator / runtime (routing, delegation, approval gates)
- Tool gateway (allow/deny, parameter constraints, egress control)
- Sub-agents (least privilege, scoped roles)
- Ski

[Read the thread](https://github.com/agentskills/agentskills/issues/138) · 2026-02-13 · closed · external user · 0 comments

### Clarify whether nested skills are allowed

## Problem

The current docs and spec don't clarify whether a skill can reference and invoke other skills by name. For example, can a skill's prompt tell the agent to "run the `/foo` skill" as part of its workflow?

It's unclear if:

- A skill can instruct the agent to execute another skill by name (e.g., "now run the `code-review` skill")
- There are any conventions for skill-to-skill delegation or chaining
- The agent is expected to resolve skill references within a skill's prompt and invoke t

[Read the thread](https://github.com/agentskills/agentskills/issues/137) · 2026-02-12 · open · external user · 3 comments

### Input and Output Schema to allow Skills as Tools in Codemode

Codemode is a pattern where MCP Tools are converted to code and become programmatic tools that support piping, lowering the LLM tokens usage.

We have implemented similar mecanism for the skills that are also usable as programmatic tools. We see ways to make the system better by supporting input and output schema definitions that will allow the LLM to create better code. Additional optional fields in the skill frontmatter could be introduced for that.

This is open for discussion and feedback.

[Read the thread](https://github.com/agentskills/agentskills/issues/136) · 2026-02-12 · closed · external user · 1 comment

### Proposal: Dynamic context injection in SKILL.md

Related to #93 (load_skill.py)

## Summary

Add a mechanism for SKILL.md content to include **dynamic values resolved at invocation time** — shell command output, environment variables, or other runtime data — so that skills can reference live project state without the model spending tokens and tool calls to gather it.

## Problem

Today, SKILL.md content is static text. When a skill needs live data (git diffs, PR metadata, build status, environment info), the model must:

1. Read the skill inst

[Read the thread](https://github.com/agentskills/agentskills/issues/124) · 2026-02-06 · open · outside contributor · 1 comment

### Proposal: Add `agents` field for skill scoping in multi-agent workflows

## Summary

Add an optional `agents` field to the YAML frontmatter that controls which agent instances receive a skill's description in their context.

## Problem

The current spec assumes a flat model where all skills are exposed to all agents. In multi-agent architectures (orchestrators, planners, executors, validators), this causes:

1. **Context bloat** - Every agent receives descriptions for skills it will never use
2. **Role boundary violations** - A planner agent seeing executor skills ma

[Read the thread](https://github.com/agentskills/agentskills/issues/111) · 2026-01-30 · closed · external user · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/agentskills/agentskills/issues).
