AI agent skills are reusable instructions that teach an assistant how to complete a specific job. For marketing content, useful examples include a multi-shot UGC ad workflow, a narrated explainer, and a video-restyling workflow. Choose the skill by the asset you need to make, then check that your agent has the tools and source material to run it.
Advibly's public catalogue provides those format-specific skills. They can use saved product context and connected creative tools to return videos for ads or social content. A skill supplies the method—not the model, credits, credentials, or permission to publish.
Start with a concrete skill below. Once one job works, use the later handoff and architecture guidance to make it repeatable without losing facts, files, or approvals.
Marketing skills you can start with
These are examples from Advibly's published catalogue, checked on 11 September 2026—not a ranked list of the best skills or a list of every marketing capability.
- ugc-ads: turn brand context and an ad angle into a creator-style video ad. The documented method includes a creator reference, a five-shot script, approved storyboard frames, video clips, and assembly. Supply real product images; never invent customer experience for a synthetic presenter.
- explainer-videos: turn a subject or product explanation into a narrated animated explainer. Use it when the audience needs a mechanism explained, and provide the facts the narration must preserve.
- vox-explainer: create a paper-collage explainer with a beat map, visuals, motion, voiceover, and music. Choose it for an editorial visual treatment, not as permission to copy Vox's reporting or artwork.
- video-restyle: transform existing footage into another visual treatment. Start with footage you have the right to use and check that identity, timing, speech, and product details survive the change.
The catalogue also includes claymation-ad, pixar-style-ad, collage-motion, and stickman-animation. Style names do not imply studio affiliation or rights to reproduce protected characters. These are video-production methods; do not mistake them for ready-made research, independent QA, or universal social-publishing skills.
How to use one skill before building a stack
- Pick one output and inspect its instructions. For a creator-style product ad, review ugc-ads and its required inputs, tool dependencies, credit use, and stop conditions.
- Install from the published catalogue. The documented full-catalogue command is npx skills add advibly/skills; the installer also supports selecting a skill. Confirm the selected skill is available in your client. This is setup guidance, not a claim of a test run in every client.
- Connect Advibly through your client's supported MCP and sign-in flow. Confirm the intended brand, product assets, generation tools, and credits before starting.
- Give it a bounded brief: create a vertical problem-solution ad for this product, use these photos and approved claims, and show the script and storyboard before video rendering. Include the audience, CTA, target duration, and budget.
- Inspect the actual file. Check product depiction, spoken claims, captions, audio, and export format. Ask the agent to return the file and generation identifiers; a script alone is not the finished ad.
To use the video as social content, add the destination-specific caption, format, account, and schedule after it passes review. Advibly has supported scheduling and publishing operations, but the chosen skill and connected client must expose the steps you need. Keep generation and publishing authorization distinct.
Skill, tool, agent, MCP server, and workflow are different things
These terms often get folded into “automation,” which makes a system sound complete before it is.
- An agent interprets a goal, chooses actions, and works toward an outcome within its permissions.
- A skill gives the agent reusable procedural knowledge for a specific class of work.
- A tool performs an action, such as retrieving brand context, generating an image, or scheduling a post.
- An MCP server can expose tools, resources, and prompts to an agent through the Model Context Protocol.
- A workflow connects decisions and actions into an end-to-end job, including verification and approval.
Official documentation from OpenAI and Anthropic describes a skill as a plain-text playbook or directory centred on a SKILL.md file, with optional references, scripts, and assets. The MCP specification describes tools separately as functions that can perform actions.
That boundary matters. A skill can teach an agent when and how to call a video-generation tool. It does not provide the model, credits, credentials, or permission to publish the result. Installing instructions is not the same as installing capability.
The five-skill stack for marketing production
Organise skills by production stage, not by whichever AI product happens to be fashionable this week. The stage model survives tool changes because each skill owns a stable responsibility and passes a verifiable output forward.
|
Stage |
Skill responsibility |
Required input |
Verifiable output |
Human gate |
|---|---|---|---|---|
|
Research |
Resolve the question, sources, claims, and uncertainty |
Audience, business decision, current product context |
Dated evidence map and unresolved gaps |
Approve risky or ambiguous premises |
|
Creative planning |
Turn evidence into a format-specific plan |
Evidence map, brand truth, channel, constraints |
Script, storyboard, or asset brief tied to source claims |
Approve before expensive production |
|
Production |
Use the correct tools and preserve run state |
Approved plan, references, model constraints, budget |
Generation IDs and retrievable assets |
Approve paid renders, rerenders, or scope expansion |
|
QA |
Verify truth, fit, completeness, and delivery |
Exact inputs, outputs, identities, and evidence |
|
Resolve material exceptions |
|
Publishing |
Adapt and deliver only approved output |
Passed asset, channel, caption, destination, schedule |
Destination receipt and live identifier |
Explicit approval for the external action |
This is a responsibility map, not a requirement to create exactly five files. A small team may combine research and planning. A high-risk workflow may separate factual review, brand review, and technical QA. Preserve the boundaries even when the implementation is compact.
1. Research must return decisions, not a browser history
A research skill should start with the question the creative needs to answer. Its output should distinguish verified claims, owned product truth, calculations, editorial inference, and unresolved uncertainty.
For a launch ad, “collect competitor examples” is not a sufficient instruction. A stronger skill identifies the audience, offer, claim boundaries, evidence date, and the specific creative decision each source changes. If a claim cannot be supported, the skill should mark the gap rather than passing confident fog into the brief.
2. Planning must bind the concept to the evidence
The planning skill turns approved facts into a script, storyboard, shot list, or static concept. It should preserve the identity of important claims and source assets.
If the research output labels a product capability as CLAIM-04, the storyboard should identify the scene or frame where CLAIM-04 appears. This gives QA something concrete to verify. Without that binding, each stage paraphrases the previous stage until the final creative is several confident steps away from the source.
3. Production must expose cost and run state
A production skill should preflight its real dependencies: available tools, connected account, credits or budget, accepted file types, model constraints, and required source assets. It should not discover after three failed generations that the runtime cannot retrieve the reference image.
Store the generation ID and resulting asset location for every attempt. If the second clip fails, the workflow should be able to retry that clip without regenerating the whole set. Paid generation, extra rerenders, brand changes, and publishing should have explicit stop conditions rather than being smuggled into “finish the task.”
4. QA needs the exact inputs and outputs
A QA skill cannot verify “the latest version” safely. It needs the exact brief, source identities, generated files, and relevant claims. Its receipt should state what passed, what failed, and whether the defect can be corrected without changing the approved direction.
The important separation is between creation and verification. A production skill marking its own work complete is useful status, not independent evidence that the asset is truthful, on-brand, channel-ready, or approved.
5. Publishing is a separate consequential action
The publishing skill should receive only passed assets and approved copy. It should know the destination, account, schedule, and adaptation rules for that channel. Its completion evidence is not “scheduled successfully”; it is a retrievable destination receipt or live identifier.
Keep publishing separate from production even if one platform exposes both capabilities. The MCP tools specification warns that tool annotations should not be treated as inherently trustworthy and recommends confirmation around tool use. A reusable instruction file does not make an external side effect harmless.
The handoff contract that turns separate skills into a system
Every stage should expose the same six-part contract:
identity → inputs → decisions → outputs → evidence → failure state
Here is what each field must answer:
- Identity: Which project, brand, deliverable, version, and run is this?
- Inputs: Which exact context, sources, references, approvals, and constraints were used?
- Decisions: What did the skill choose, and which rule or evidence supported the choice?
- Outputs: What did it create, in what format, and where can the next stage retrieve it?
- Evidence: What proves the output matches the request and preserves the relevant source truth?
- Failure state: Is the work passed, correctable, blocked, or waiting for a named approval?
A shared handoff contract prevents ambiguity from moving downstream. A skill collection may contain excellent instructions and still fail as a production system if one stage says “done” while the next cannot identify what changed, which asset passed, or whether anyone approved the spend.
A compact handoff example
Suppose a founder asks an agent to turn a product launch into three ads and schedule the approved assets.
- Research returns a dated claim ledger for the launch, including two verified capabilities and one unsupported performance claim that must not be used.
- Planning returns three concepts tied to those claim IDs, plus format, channel, source asset, and cost assumptions.
- Production confirms its connected tools and credits, pauses for approval, then stores a generation ID for each render.
- QA checks the final files against the approved concepts and claim ledger. It passes two assets and returns one for correction because the product screen is inaccurate.
- Publishing receives only the two passed files. It requires confirmation of the account and schedule, then returns the destination IDs.
The identity chain lets the team correct one asset without reopening the research, regenerating the other two, or accidentally publishing the rejected version.
When a reusable skill is the wrong choice
The strongest alternative is a short operating manual with direct tool use. It is often better when the workflow is rare, changes every week, or depends on judgment that cannot yet be expressed as stable inputs, decisions, and checks.
Use a reusable skill when:
- the same decision sequence repeats;
- inputs and outputs can be defined clearly;
- known failures are worth encoding once;
- the result can be verified;
- the runtime assumptions can be documented.
Keep the workflow manual when:
- the task is genuinely one-off;
- the process is still being discovered;
- most steps require fresh executive judgment;
- no reliable completion evidence exists;
- maintaining the skill would cost more than repeating the work.
A useful test is to examine the last three runs. If the same instructions, mistakes, and checks recur, package them. If every run needed a different objective and approval path, the “skill” may only be a long prompt wearing a uniform.
Portability requires a contract and an adapter
A SKILL.md file may be readable across several agent environments, but readable does not mean behaviourally identical. Clients can differ in discovery rules, frontmatter, invocation, execution context, available tools, filesystem access, and approval controls. Anthropic's Claude Code documentation describes its own invocation and context options; those details should not be assumed elsewhere.
Treat portability as two layers:
- Portable core: job definition, required inputs, decision rules, output contract, verification, and stop conditions.
- Client adapter: metadata, paths, tool names, authentication, context loading, and invocation behaviour for a specific runtime.
Then run a small smoke test in every supported client. Confirm that the skill loads for the intended trigger, can see its dependencies, stops at the right approval gate, and returns the expected receipt. Installation alone proves very little.
For consequential workflows, pin the reviewed version. NVIDIA's skills catalogue adds provenance, review, signing, compatibility metadata, and machine-readable skill cards around reusable instructions. Your system may not need that full apparatus, but it should treat third-party skills as dependencies to inspect, not prompts to trust on sight.
Common failure modes to design out
- Trigger ambiguity: The skill description is so broad that it loads for the wrong job. Name the job, exclusions, and required inputs.
- Hidden tool dependency: The instructions require a tool, credential, or permission the runtime does not have. Run a preflight before work begins.
- Version drift: The skill changes after approval. Record or pin the reviewed version for consequential runs.
- Context bloat: Every reference loads on every task. Load only the evidence and instructions needed for the current job.
- Unchecked side effects: The production step also spends, updates brand truth, or publishes. Separate those actions behind explicit approval.
- Portability theatre: The file installs but relies on unsupported paths or client-specific metadata. Document the adapter and smoke-test it.
- No terminal evidence: The agent reports completion without a retrievable output or receipt. Define completion before the run starts.
Where Advibly fits in the stack
Advibly fits the creative-planning and production side of this architecture. Its published agent skills package format-specific workflows for UGC-style ads, explainers, animation, collage, and video restyling. Those skills can use saved brand and product context and call Advibly's creative tools through MCP. The documented install command is npx skills add advibly/skills.
That does not make Advibly the research, governance, or independent QA layer for every marketing workflow. It gives an agent a reusable route from product context into creative production, with supported scheduling and publishing available through the workspace and native tools. Generating an asset and authorising its external use remain different decisions.
If you already operate from an agent workspace, review the Advibly skills catalogue and the MCP setup guide. The AI agent workflow blueprint covers the wider system boundary, while the MCP marketing workflow guide focuses on the tool layer. Start with one repeated creative job. Define its handoff contract, confirm the live tools and cost before generation, and keep final publishing behind a separate approval.