The failure was in the guidance reaching generation
When I reviewed Launcherry's channels, I found missing platform guidance in parts of the generation workflow and drafts that repeated internal goal labels instead of giving readers a useful next step. I needed to fix how expertise reached generation. Improving the fluency of the copy alone would leave both problems unresolved.
I needed a way to carry researched expertise into the moment the product generated a deliverable. I directed a library of reusable AI skills: one shared core and 16 channel-specific files for planning, writing and asset direction. The library is implemented in local development; public availability depends on the release and channel conditions.
I need evidence that the model receives the guidance; the document alone cannot establish that. Having a model receive it does not establish that the resulting campaign is useful. I treated authoring, integration and evaluation as separate responsibilities, each requiring its own evidence.
Begin with the deliverable a person needs
My starting point was the platform and delivery type. An organic post, a paid ad and a short video script place different demands on the work. The writer needs to understand what the audience encounters, what the format can carry and what next action fits the communication. A platform name appended to generic instructions cannot express all of that.
I researched the requirements of individual channels and turned them into guidance tied to the output. In the Launcherry library, the channel-specific material supports the angle, the writing and the assets. Shared standards provide consistency across those stages. This gives the generation workflow relevant guidance without requiring each file to restate the whole product philosophy.
For another team, I would start with the recurring deliverable that causes the most avoidable rework. Define its audience, purpose and constraints, then inspect actual failures. A skill earns its place when it addresses that repeated work. The evidence should explain why the guidance is needed, rather than simply show that a file exists.
Separate common standards from channel judgment
The shared core provides a place for standards that should remain consistent. The channel files carry the distinctions that make the deliverable appropriate to its destination. This separation is a maintenance choice as much as a writing choice: a common requirement has one home, while a channel-specific correction can remain local to that channel.
I can also use that separation to diagnose disagreements. If every channel produces the same kind of weak next step, I need to examine shared guidance and the surrounding generation workflow. If the problem belongs to a particular delivery format, its specialist guidance becomes a more relevant starting point. The location of a rule should reflect its scope.
I describe these assets as reusable domain skills. Launcherry loads their guidance into its own generation code. That is distinct from claiming that every file is a drop-in package for every coding agent. The wider Agent Skills specification describes a portable packaging approach; compatibility with a particular host still needs to be established.
Connect the skill to the work it is meant to change
In Launcherry, the generation code loads the shared core and channel guidance. The labelled guidance blocks identify the material intended for the model; documentation outside those blocks remains for the people maintaining the library. The connection between file and generation stage is part of the implementation, rather than an assumption about how the system behaves.
I use that boundary to keep the editorial purposes clear. Maintainers need context about a skill, its intended use and how to assess it. The model needs the instructions relevant to the current task. Combining those purposes carelessly can send maintenance notes or evaluation language into the generated result.
I saw this problem in the earlier goal-label leakage. A planning label may be useful internally while making poor campaign copy. I want the skill to help translate intent into reader-facing language. The founder should receive a usable next step for their audience, without having to interpret the generation system’s terminology.
Check the skill and assess its outputs separately
The library has an authoring standard with mechanical checks. Those checks can establish that the expected guidance blocks exist and that the files meet the required structure. They are useful because malformed guidance can fail before any question of writing quality arises.
Output evaluation asks a different question: did the workflow produce an appropriate result for this product and channel? I keep evaluation criteria separate from the generation guidance. That gives review its own role, rather than treating compliance with the writing instructions as proof of success.
A practical evaluation should compare relevant examples, record the failure being investigated and keep the surrounding workflow in view. A result may reflect the skill, the model, the supplied business context or a later validation step. My article on AI output evaluation explains why those distinctions matter when a field can pass validation and still be unusable.
Model-agnostic guidance still needs model-specific evidence
I wrote the guidance without making it dependent on one model vendor. That supports reuse and lets the domain knowledge survive a provider change. It does not establish identical behaviour across models. A new model can interpret a requirement differently or fail a constraint that an earlier model handled.
My acceptance decision therefore belongs to the combination being evaluated: guidance, context, model and generation workflow. A successful run gives evidence about that combination. It should not become a claim that the skill guarantees good output everywhere.
I treat research, integration, evaluation and maintenance as parts of skill engineering. Writing instructions is one part of that work. I build the connections that make expertise usable inside a product, then review what the product actually returns. The Launcherry case shows this library in its product context; the development harness article explains the delivery practice around it.
Originally published at ivanped.ai: Building reusable AI agent skills: From domain expertise. More of my work: ivanped.ai
Top comments (0)