Make *skills* spec future proof

Skills are a great formalization of a problem that many of us solved with our own custom implementations. Having a formal spec, like for the “AGENTS.md” spec, will decouple an agent if platform business logic from the runtime it executes on, and allow to share/compose that business logic.

I would like to suggest a few ideas and requirements for the *skills* spec:

- SKILLS should be defined as a contract, not an implementation. Having the spec defined as file-based is very limitative.
- Edge devices may not have access to a file system per se. The spec should support multiple locations, including remote ones.
- The skills registry (current assembly of “skill.md” frontmatters) should offer both direct system prompt embedding for simplicity/performance, and querying of a remove registry. Required to support contexts where thousands of skills may be present. Think query interface like ‘concept7’ MCP tool. Find then fetch. Use-case: In manufacturing, maintenance instructions for thousands of SKUs.
- Skills can be static and deployed as file-based documents.
- Skills can also be dynamically created/updated. For example, an HR agent may work with their human counterpart to define an *employee on-boarding workflow*. That’s a perfect example of a skill that includes basic knowledge, workflow steps, and tool access definitions. That skill need to be able to evolve for this particular tenant/user.
- Skills, which may include sensitive knowledge, must support some form of tagging to allow for integration into the platform permission management system/security.
- Skills should be modular while conforming to a higher-level schema. For instance, the frontmatter allow for identifying a skill from its definition. What if I want to find all the skills *related* to an operation context, or query for the *behavioral traits* to adopt when executing a specific skill? Skills could include a predefined set of facets, along with extendable custom facets. Think of querying/accessing a skill with *projections* like we do when accessing a database table. When an agent executes an employee on-boarding workflow, the agent needs the knowledge of the workflow steps. It would only be noise if the *legal implicaitons* from the skills were also loaded. These however would be needed when *planning* the employee on-boarding.
- Skills should be versionable, to allow them to live in approval workflows, and support easy rollbacks if needed.
- To streamline skills deployment from dev->test->staging->prod environment, and be efficient when thousands of skills are involved, skill fingerprints (hash) must allow for the fast identification of changed skills.
- To alleviate tool and mcp server definitions/schemas to pollute an agent system prompt, tools and mcp servers must be progressively discovered as part of skills introspection (in addition to being bolted onto the agent directly for often used tools).
- Skills, if they provide knowledge, should support I18N.
- Skills, as for database backed data, should be cluster-aware. In a round-robin cluster deployment, file-based skills will exist in different versions while the cluster gradually updates. A database backed skill storage would behave as debase data/schemas who must be backward-forward compatible and are updated first as part of a cluster update.

Happy to discuss as I have already implemented most of this before MCP even came to be.