How to Build a Simple AI Skill for One Marketing Task

Repeated instructions can become a reusable AI capability when they are given one clear job, defined inputs, useful instructions, an expected output and a human review boundary. Start with a one-page outline for one safe task, including what the Skill must not do.

The word Skill is platform-aware rather than universal. Current AI products use provider-specific names, structures and permissions for reusable capabilities. The outline below gives you a way to think clearly before you use a platform's own format.

What is an AI Skill?

An AI Skill is a reusable package of instructions and, depending on the platform, supporting examples, files, templates or code for a particular task. It is intended to make a capability available again without rebuilding all the guidance from scratch.

The exact meaning depends on the platform. OpenAI's current Skills guidance describes reusable, shareable workflows that can include instructions, examples, code and supporting resources. Anthropic's Agent Skills documentation describes modular capabilities that package instructions, metadata and optional resources, with platform-specific loading and runtime behaviour.

Those are provider examples, not a promise that one Skill can be moved between tools unchanged. A Skill may be automatically used when relevant on one platform, while another may require a different installation, activation or file structure. Check the current documentation for the platform you plan to use.

How is a Skill different from earlier building blocks?

The distinctions matter because each building block solves a different problem.

• A prompt gives an AI tool an instruction for a particular request.
• A context file stores stable background that may support several tasks.
• A workflow map shows how one task moves from input to output and where a person checks it.
• A Skill packages reusable task guidance and, on some platforms, supporting resources.
• An agent may be configured to carry out actions or use tools with a different level of autonomy.

This article stays with the Skill outline. It does not create a prompt library, a context-file system, a workflow map, an agent or a testing programme.

The five parts of a first Skill

The following five-part model is a practical recommendation for a first outline. It is not a universal Skill specification.

1. One job

State the single task the Skill is meant to support. A useful job is narrow enough to explain in one sentence, such as “organise approved marketing notes into possible themes” or “turn a defined brief into a draft outline”.

Avoid jobs such as “run the marketing” or “manage all content”. Those descriptions hide too many decisions, inputs and risks inside one capability.

Ask what the person wants to be able to request again. If the answer contains several unrelated deliverables, split it into smaller Skills or keep it as a normal task.

2. Clear inputs

List what the Skill may receive and what the person must supply. Inputs might include an approved brief, a short set of notes, a topic, an intended audience or a defined output format.

Make the boundary visible. Do not assume the Skill can safely access every folder, conversation or source. Do not include personal data, confidential material, credentials or employer-sensitive information unless the relevant permission, tool policy and organisational process are in place.

3. Useful instructions

Describe how the Skill should handle the input. The instructions might say to use the supplied material first, preserve uncertainty, flag missing information, write in UK English or return a defined structure.

Keep the instructions useful and short enough to review. A Skill is not a place to hide every preference, old rule or possible workflow step. If the instructions become a complete operating manual, the job is probably too broad for a first Skill.

4. Expected output

Describe the shape and purpose of the result. It might be a short list of themes, a draft outline, a structured summary or a set of questions for a person to answer.

An expected output is not an expected quality level. Saying “produce a reliable outline” does not make the outline reliable. Describe what the result should contain and who will decide whether it is useful.

5. Review boundary

State where a person checks, edits, approves or stops the work. The review might ask whether the output follows the approved inputs, fits the intended audience, contains unsupported claims or needs specialist review.

Also state what the Skill must not do. Examples include inventing sources, using unauthorised private information, making an irreversible change, contacting someone or presenting a draft as approved.

The review boundary keeps the capability human-led. It does not guarantee that every problem will be found, and it does not replace the broader human review or testing appropriate to the task.

A one-page illustrative Skill outline

Illustrative outline: This fictional outline shows the five parts without claiming that the Skill has been installed, tested or used in real work. It is not a client method, employer example or performance result.

Skill name: approved-note-theme-organiser

One job:
Organise a small set of approved marketing notes into three possible themes.

Inputs:
- The approved notes supplied for this task.
- The intended reader and question.
- Any required output format.

Useful instructions:
- Use only the supplied notes.
- Keep uncertainty visible and flag missing information.
- Return three themes with a short explanation for each.
- Use clear UK English.

Expected output:
Three possible themes, each linked to the supplied notes and the reader question.

Review boundary:
A person checks the themes, removes unsupported suggestions and decides whether one can move to the next step.

Must not do:
- Invent sources, figures, quotes or product details.
- Use private or unauthorised information.
- Publish, contact anyone or make changes outside the agreed task.

The outline is deliberately modest. The job, inputs and output are visible, and the person remains responsible for deciding what happens next. A real platform may require different metadata, folders, permissions, file types or activation steps. Those details must be checked separately.

Keep platform scope visible

Before turning an outline into a platform-specific Skill, check four things:

1. What does this platform call a Skill, and where does it load from?
2. What instructions, files, scripts or examples can it use?
3. Who can install, invoke, edit or share it?
4. What tools, data or external actions can it reach?

These questions matter because current Skills documentation describes real differences between products and surfaces. A Skill may include code or supporting files, and some platforms warn that those resources can have meaningful access and security implications. Review the source and contents before use, especially if a Skill comes from someone else.

Do not describe a Skill as portable, autonomous, reliable or high-performing unless you have specific evidence for the platform, version and task. The conceptual outline is portable as a planning exercise. The implementation is not automatically portable.

Protect privacy and approval

Keep private, personal, confidential, employer-sensitive and access-restricted information out of the outline and its supporting files unless it is authorised and necessary. A Skill's reusable nature can make an unsafe instruction easier to repeat, so review the boundary before installation or sharing.

The person who owns the marketing task should decide what information is approved, what the Skill may support and what requires human review. For sensitive work, follow the relevant organisational, legal, privacy or specialist process. This article offers practical design guidance, not a security, compliance or legal assessment.

What this first Skill should not become

Do not use one starter Skill to hold every brand rule, source, task and automation step. A context file may hold stable background. A prompt template may handle a repeated request. A workflow map may show stages. An agent may introduce actions and permissions. A testing process may evaluate whether a workflow is worth reusing.

Keeping the first Skill narrow makes its purpose and review boundary easier to see. If you cannot describe its job, inputs and stop conditions clearly, it is not ready to become a reusable capability.

Your next step

Choose one safe, recurring marketing task and write a one-page outline with these headings:

1. One job: What single task will it support?
2. Inputs: What may it receive, and what is authorised?
3. Useful instructions: What should it do, and what should it flag?
4. Expected output: What should it return for a person to inspect?
5. Review boundary: Who checks it, who approves the result and what must it not do?

Read the outline as if you were going to install or share it. Remove unnecessary or sensitive material, then check the current platform documentation before using its implementation format.

The goal is not to create a clever autonomous system. It is to make one useful capability clear enough for a person to review, approve and improve deliberately.

Further reading

• OpenAI Help Center: Skills in ChatGPT
• Anthropic: Agent Skills overview
• Anthropic: Skill authoring best practices
• What Is AI-Assisted Marketing?
• How to Map a Simple AI Marketing Workflow