Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/agent-skills-search-server/issues.md or /mcp/agent-skills-search-server/issues.json, or Pod over MCP.

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.

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, metadata is described as:

Arbitrary key-value mapping for additional metadata.

However, the later [`meta

Read the thread · 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 · 2026-06-09 · closed · external user · 6 comments

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

Summary

Skills define what agents can do. But there's no standard for how to assemble skills into a running agent — or how to make skills accessible to models that can't speak MCP.

This proposal introduces two complementary ideas:

  1. AgentFile — a declarative configuration format (like Dockerfile, but for agents) that composes skills, models, credentials, and runtime behavior into a deployable agent<

    Read the thread · 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 · 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 · 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 · 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 · 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!

    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 · 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 · 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

    npx skills add kensaurus/cursor-kenji

    Links

    Read the thread · 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 · 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

    ---
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).