AI delivery / Skill engineering
Building reusable AI agent skills: From domain expertise
How I translated platform research into a shared core and 16 channel-specific skills, then connected the guidance to Launcherry’s generation workflow.
Explore the Launcherry seriesThe failure was in the guidance reaching generation
My channel review of Launcherry found two problems worth addressing together. Platform guidance was missing from parts of the generation workflow, and some drafts repeated internal goal labels where a reader needed a useful next step. More fluent writing would not, by itself, correct either problem.
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 had three jobs to verify: write sound guidance, connect it to generation and assess the campaign it produced. A well-written file can sit unused. A model can follow every instruction and still return weak copy.
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 begin with the recurring deliverable that causes the most rework. Define its audience, purpose and constraints, then inspect actual failures. Build the skill around that evidence so its purpose remains clear as the library grows.
Separate common standards from channel judgment
Common requirements live in the shared core. Channel files handle the choices specific to an organic post, a paid ad or a video script. This also keeps maintenance manageable: update a common rule once, and correct a channel problem where it belongs.
It also makes disagreements easier to diagnose. 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.
These are reusable domain skills loaded by Launcherry’s generation code. Using them in another host would require integration and compatibility checks. The wider Agent Skills specification describes a portable packaging approach; my library’s current integration is with Launcherry.
Connect the skill to the work it is meant to change
Launcherry’s generation code loads the shared core and channel guidance. Labelled blocks hold the instructions intended for the model. The surrounding documentation helps people maintain the library. That separation keeps maintenance notes out of campaign copy.
That boundary helps preserve editorial clarity. 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.
The earlier goal-label leakage is a concrete reminder of this problem. 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 whether the campaign works for this product and channel. I keep its criteria separate from generation guidance so a draft has to earn acceptance on the quality of the deliverable.
I compare relevant outputs and record the failure under investigation. The cause may sit in the skill, model, business context or validation step. My article on AI output evaluation follows one such failure: copy that passed a field-length check but left the reader with an unfinished thought.
Model-agnostic guidance still needs model-specific evidence
The guidance is independent of one model vendor, so the domain knowledge can survive a provider change. I still check it with each model: a new model may interpret the same instruction differently or miss a constraint the previous one handled.
I assess the guidance, business context, model and workflow together. When that combination produces useful campaigns, I retain the examples and conditions behind the result. A provider change gives me a reason to evaluate it again.
The wider lesson is that skill engineering includes research, integration, evaluation and maintenance. 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.