Comment by btown | Hacker News Reader

Comment by btown | Hacker News Reader

Something that’s under-emphasized and vital to understand about Skills is that, by the spec, there’s no RAG on the content of Skill code or markdown - the names and descriptions in every skill’s front-matter are included verbatim in your prompt, and that’s all that’s used to choose a skill.

So if you have subtle logic in a Skill that’s not mentioned in a description, or you use the skill body to describe use-cases not obvious from the front-matter, it may never be discovered or used.

Additionally, skill descriptions are all essentially prompt injections, whether relevant/vector-adjacent to your current task or not; if they nudge towards a certain tone, that may apply to your general experience with the LLM. And, of course, they add to your input tokens on every agentic turn. (This feature was proudly brought to you by Big Token.) So be thoughtful about what you load in what context.

See e.g. https://github.com/openai/codex/blob/a6974087e5c04fc711af68f...

Some agentic systems do apply RAG to skills, there's nothing about skills that requires blind insertion into prompts.

This is really an agentic harness issue, not an LLM issue per se.

In 2026, I think we'll see agentic harnesses much more tightly integrated with their respective LLMs. You're already starting to see this, e.g. with Google's "Interactions" API and how different LLMs expect CoT to be maintained.

There's a lot of alpha in co-optimizing your agentic harness with how the LLM is RL-trained on tool use and reasoning traces.

Honestly the index seems as much a liability as a boon. Keeping the context clean and focused is one of the most important things for getting the best out of lmms. For now I prefer just adding my md files to the context whenever I deem them relevant.

Skills are much simpler than mcps, which are hopelessly overengineered, but even skills seem unnecessarily overengineered. You could fix the skill index taking up place in the context, by just making it a tool available to the agent (but not an mcp!).

but that's same for MCP and tools, no?

Yes. Infact you can serve each Skill as a tool exposed via MCP if you want. I did the same to make Skills work with Gemini CLI (or any other tool that supports MCP) while creating open-skills.

1. Open-Skills: https://github.com/BandarLabs/open-skills

Interesting. Skills on MCP makes a lot of sense in some contexts.

A consultant started recommending the Azure devops MCP and my context window would start around 25% full. It’s really easy to accidentally explode your token usage and destroy your context windows. Before I’d use az cli calls as needed and tell the agent to use the same, which used significantly less context and was more targeted.

Reply on news.ycombinator.com