AI Skills

Use a skill when the same job repeats and a fresh prompt still yields a different draft: new headings, a new tone, a fact that was not in the source, or a dropped section because you forgot to mention it this time. Ad hoc prompting is enough for a task you will never run again. It is the wrong unit of work for a weekly send.

An AI skill packages that repeated job. It holds the trigger (when to use it), the steps (what to do, in order), and the sources it may use. Empty stays empty if a step has no source. Do not invent a procedure to make the pack look complete. The owner still reviews skill output.

Claude, ChatGPT, Cursor, and Copilot all belong in the same class here: assistants that can load packaged instructions and run them against the files you attach. The product name matters less than whether the skill is specific enough to reuse.

If you already keep related files together in AI Projects, keep the project as the shelf of materials. Write a skill for one named job, not for everything in the project.

Give the job a name a colleague would use without explanation. "Weekly stakeholder update" is a job. "Be helpful with status" is not.

State the trigger in one sentence: this skill runs when these inputs exist and this draft is due. For a weekly stakeholder update, the trigger is: this week's ticket export and last week's notes are in hand, and you need a Friday draft in the team's usual template.

Then list the steps the person already follows. Copy the real sequence from how the work is done today. If you cannot name a step without guessing, leave it out. A short skill that matches the job beats a long skill that describes a process nobody runs.

One example: Maya sends a Friday update to the same three stakeholders. She pastes a ticket export and last week's notes into an AI assistant, then types a long prompt about tone, length, and not making things up. Some weeks the draft invents a blocker that was not in the export. Some weeks it omits Risks because she did not ask for that section in the prompt. What she needs is not a cleverer paragraph. She needs a skill that names the job, the trigger, the steps, and the sources.

Sources are the only places the skill may take facts from. Name each one. For Maya's update, the allowed sources are the ticket export attached to this run, last week's notes, and the team's existing update template. If this job also reads live systems through MCP, list those tools as sources only when the job actually uses them. Do not add a source because it might be useful later.

Company policy is a source only when you point at a real document you can attach or cite by name. Inventing a company policy in the skill, for example a line that says delays over two days must be escalated, teaches the assistant to state a rule nobody approved. If the team has no written rule, the skill says nothing on that point.

Write the empty-field rule in the skill itself. The failure to prevent is a skill that silently fills missing inputs. If the export has no item under Risks, the draft's Risks field stays empty, or it states that the source listed none. It does not guess. It does not reuse last week's risk because the field looked thin. It does not invent rows so a table looks finished.

In the template, prefer a visible blank over a hedged sentence. "Risks:" with nothing after it is clearer than "Risks: nothing major to report" when the export was silent. The second sentence is a fill. The first is an empty field.

That is the quality bar for this page: a skill that cites the trigger, the steps, and the sources it may use. If a step has no source, that step stays empty. A pack that looks unfinished for an honest reason is safer than a pack that looks thorough because you filled gaps yourself.

Draft the skill as a short document, not as a chat log. Include six parts:

1. Job name
2. Trigger
3. Ordered steps
4. Allowed sources, each named
5. Blanks: which fields stay empty when the source is silent
6. Output shape: the template to fill, and a rule to add nothing extra

For Maya's update, the steps can be: read this week's ticket export; read last week's notes; carry forward only items the export still shows as open; fill the template in order (Progress, Risks, Asks); leave any section blank when the sources do not support a sentence; stop. No closing summary unless the template asks for one.

Install the skill where your assistant loads reusable workflows. Across Claude, ChatGPT, Cursor, and Copilot that means putting the instruction pack or skill file in that product's usual place, then calling the job by name when you want this run. Do not paste the full skill into every chat. Install is what makes the name enough.

At run time, type the job name, attach this week's sources, and do not re-explain the template. If you re-explain the template every Friday, the install did not take, or the skill that loaded is not the one you wrote.

If you later want the same job to run without you in the loop, that is a different decision. workflow automation is the place to judge a reviewed draft versus a scheduled pipeline. This page stays on enable: a person still owns the send.

Run the skill on a real recent week, not on a made-up export. Check three things.

Did it follow the steps in order, or did it jump to a polished narrative? Did every factual claim map to a named source? Did blanks stay blank?

When you run it, attach only the sources the skill names. If the skill lists the ticket export and last week's notes, do not also dump a slide deck, a chat log, and a strategy memo for context. Extra files are how silent filling starts: the model finds a sentence somewhere and treats it as this week's fact.

If Risks contains a plausible sentence that was not in the export, the skill is wrong. Tighten the empty-field rule and run again. If the draft cites a policy you never attached, you invented a company policy in the skill. Delete that line from the pack. You did not forget a source. You added fiction.

Treat the result as a draft in your editor. Do not treat skill output as already sent. A skill does not mail, post, or file. You read it, you correct it, you send it. The owner still reviews skill output even when the run looks clean. A missing Ask, or a risk carried forward after the export already closed it, is still yours if you forward the draft unread.

After a good run, keep the skill small. A new exception becomes a step or a named source, not a paragraph of extra caution. When the job changes, change the skill. If you rewrite half the instructions every Friday, you do not have a skill yet. You have a conversation stored under a file name.