Wiring Agent Skills into Omnilude

Introduction

Earlier, I wrote a post introducing Skills and Agent Workflows.

While reading through it, I found myself thinking, Skills could be very useful when they are connected to AI chat.

This post is a build log that starts from that thought. I wanted to take Skills out of tools like Claude Code and Codex, let an Agent call them inside a real workflow, and see what changes. If this works well, maybe even lower-spec LLMs can inch a little closer to Jarvis.

Defining Skill in One Sentence

The shortest definition is this: a skill is a reusable work package that teaches an agent how to handle a specific kind of task with a repeatable order and criteria.

Anthropic's public guide also describes a skill as a folder centered on SKILL.md, with scripts, references, and assets when needed. What matters is not the shape but the principle. Instead of stuffing all knowledge into the prompt every time, you let the agent open the skill body and reference files progressively, only when needed.

This matters more than it seems. General-purpose agents are smart, but they wobble under repetitive tasks. Even in the same repository, with the same request from the same person, the tone, structure, and missing details can vary. A skill is a device for reducing that drift.

The three principles I care about most are these. First, progressive disclosure, where the agent opens deeper documents only when needed. Second, composability, where one skill does not try to solve the whole world alone and instead works with other skills. Third, portability, so the skill is not tied to a single UI or tool.

The Skill Chains I'm Building

In my local repository, there are 25 skills under .codex/skills. They each take responsibility for recurring work such as document generation, API implementation, backoffice CRUD, SSE, story pipelines, translation, review, and commit workflows. Under .agents/skills, I keep the same catalog aligned for reuse from another surface.

There is also a reason Codex suddenly appears after I keep mentioning Claude Code. In Korea, there was recently an almost 90% discount event for OpenAI Pro through Kakao. It was a good opportunity, so I have now switched over to Codex.

Back to the main point, the set of skills I use most often is fairly clear. prd-generator turns requirements into a PRD that follows our document rules, and endpoint-implement-skill fixes the implementation pattern from Entity to Controller. When needed, frontend-task-handover continues into a handover document for the frontend team, and branch-review checks regressions and risk at the end.

In other words, I tend to see skills more as a chain than as isolated features.

In fact, CLAUDE.md already spells out which skills should be connected first for each type of work. For example, API work follows the chain prd-generator -> endpoint-implement-skill -> frontend-task-handover, while backoffice work follows prd-generator -> backoffice-crud-skill -> frontend-task-handover. At that point, a skill feels less like a helper feature and more like an operating rule for work.

An interesting detail is that this post itself stands on the same philosophy. The blog-post-writer skill I am using right now is designed to align category selection, reading time, tone, excerpt length, canonical URL, thumbnail prompt, and the import JSON schema all at once. Even writing is no longer just a matter of intuition. It is packaged into a repeatable output format.

Skills and Assistants

Once a skill enters the product, it can no longer be explained by SKILL.md alone. If you use the current-weather-checker detail blueprint as a reference, the real skill is closer to a runtime unit that bundles not just instructions and references, but also executable code, metadata, network policy, and trigger strategy. That is why I now look at a skill not just as a folder structure, but as a structure that answers what is stored, what is executed, and how it connects to the assistant.

Overview of Skill Structure

If you follow the current-weather-checker blueprint, the substance of a skill is more layered than it first appears. What you see on the screen first is the name and description, but behind that sit Instructions, Scripts, References, Assets, Metadata, and Runtime Policy. This composition is what allows one skill to only enrich context, another to run directly in a sandbox, and another to control external network access safely.

In short, a skill is not just a prompt file. It is closer to a definition object that bundles descriptive text + execution resources + operating policy. In particular, for script skills, execution rules such as networkPolicy and allowedDomains determine the real permissions. Reading body alone is not enough to understand what that skill can actually do. That is exactly why blueprint documents are useful. They restore the structure that sits behind the screen in one pass.

Overview of Assistant Integration

The next important thing is not the skill itself, but who owns the skill, under what conditions it is invoked, and through which path it runs after selection. In the Omnilude structure, a skill is not loosely attached to an agent. It is mapped to an assistant, and the orchestrator reads that mapping and trigger information to determine the actual execution path. Executable skills flow toward the sandbox side, while context-only material flows toward the final answer prompt.

Isolated Execution Environment

The scripts for executable skills do not run directly inside the assistant process. AssistantSkillScriptExecutor delegates execution to a separate sandbox pod through sandbox-bridge, and the script runs inside that isolated environment, taking stdin JSON as input and returning stdout JSON as output. This structure separates the assistant core from the execution code and also lets us control external access through networkPolicy and allowedDomains.

Put simply, the assistant decides what to execute, and the sandbox is where that execution is handled safely. This separation becomes more important as the number of skills grows. It lets you isolate failures, split network permissions more precisely, and later trace which script ran under which policy.

Seen through that flow, a skill is closer to a module the assistant selects and runs when needed than to a subsidiary document owned by the assistant. That is why, as attached skills become more powerful, what matters is not how long the explanation is, but how clearly mapping, trigger, execution, and observability are designed. In the end, a good skill is not just a well-written document. It is a structured execution surface that an assistant can call reliably.

Closing

If the workflow post from February 18, 2026 explained how an agent flows, this post is about how that flow can be fixed into a stable structure through skills.

A skill is not a magical option. But it is still a powerful way to bundle repeated work, working standards, reference context, output format, and execution paths into a single unit for both individuals and teams.

Next time, I want to bring more concrete cases from both implementation and operations to show how the combination of skills and assistants can improve the actual agent experience.