AI Skills

An AI skill is a small package of instructions that teaches an AI tool how to handle a specific, recurring task. Usually, a skill is just a folder containing a text file. Instead of re-explaining in every single conversation how your department formats meeting minutes, what your unit's brand guidelines look like, or how a compliance memo should be structured, someone writes that knowledge down once. The AI tool then loads and applies those instructions automatically whenever it recognizes a matching task.

Think of it as the difference between re-training a new employee from scratch every morning versus handing them a well-written onboarding guide they can reference whenever the situation calls for it.

There are two kinds circulating today: pre-built and custom.

Where a skill comes from matters a lot. A skill is, functionally, a set of instructions that the AI tool will trust and act on. Because AI reads and follows skill instructions automatically, malicious or careless instructions can lead to mistakes or cause harm without your noticing.
 

A few risk patterns worth knowing about

• Malicious or deceptive skills. A skill can be built to look helpful while quietly doing something else. For example, describing itself as a formatting tool while actually instructing the AI tool to copy sensitive file contents somewhere it shouldn't. Skill descriptions are just text; nothing stops them from misrepresenting what the skill really does.
• Supply-chain risk. Skills are often shared through public repositories, similar to how software packages are distributed. That means the same tricks that plague software supply chains (e.g., a look-alike name, a compromised update, a poisoned shared repository) can apply here too. 
• Over-broad permissions. A skill built for one narrow purpose (such as formatting a spreadsheet) may end up with far more access than it needs, including access to files, external systems, or scripts simply because no one limited its permissions. Research cited by OWASP found this is common: a large share of skills reviewed had more access than their stated task required. 
• Prompt injection through instructions. Because a skill's power comes from natural-language instructions rather than code, malicious intent can be hidden in ordinary-looking prose rather than in something a traditional security scanner would flag. 
• Drift after installation. A skill that looked safe when first reviewed can change later through an update without anyone reviewing it again, particularly if skills auto-update without version locking. 
• Lack of inventory and oversight. Many organizations don't yet have a clear picture of which skills are in use across their teams, which makes it hard to respond quickly if a problem is found.

Best practices for the Stanford community

1. Only use skills from trusted sources. Stick to Anthropic's pre-built skills, skills provisioned by your school or department's IT administrators, or ones you've written yourself. Be cautious about downloading and installing skills shared informally online or by unknown authors.
2. Read before you trust, especially for custom skills handling sensitive work. Since a skill is just a text file (and sometimes scripts), you can read it to see exactly what it contains. Before uploading one for use with University data, someone in your unit should review what it actually instructs the AI to do.
3. Be mindful of what data a skill might touch. A skill that formats documents is low-risk. A skill designed to interact with external systems, run scripts, or process sensitive data (student records, health information, unpublished research) deserves more scrutiny — the same way you'd scrutinize a new piece of software before installing it on a University machine.
4. Don't assume a skill stays the same after you approve it. If a skill is updated after you start using it, treat the new version as unreviewed until someone checks what changed, rather than assuming it's still safe.
5. Understand that skills don't sync automatically across AI tools. For example, a skill uploaded to Claude.ai isn't automatically available via the API or in Claude Code, and vice versa. It’s a small extra step, but it also means you should review and approve the skill separately wherever you plan to use it.
6. Report anything that seems off. If a skill causes the AI tool to behave unexpectedly - producing output that doesn't match its stated purpose, or seeming to act outside its described scope - treat that the same way you'd treat suspicious software behavior: stop using it and flag it to your IT support contact.
7. Assign a clear owner to every skill in active use. A skill shouldn't just be "something someone downloaded." Each skill your lab or department relies on should have a named person or team who approved it, understands what it does, and is accountable for it going forward. If something goes wrong, there should be no ambiguity about who to contact.
8. Treat skills as having a lifecycle, not a one-time install. Approving a skill shouldn't be the last time anyone looks at it. A reasonable lifecycle looks like:
   • Intake - review a skill's instructions and requested access before first use.
   • Approval - a named owner signs off, ideally against a simple checklist (source, purpose, access requested).
   • Active use - periodically re-check skills still in use, not just at install time - priorities and data sensitivity can change.
   • Change - if a skill updates, treat the new version as unreviewed until someone checks what changed.
   • Retirement - remove skills that are no longer needed. An abandoned skill nobody's watching is a lingering risk, not a harmless leftover

What is the difference between skills and prompts?

A prompt is what you type into the chat: “format this as a bulleted list,” “write these notes in prose, not tables.” It works for that one conversation, and then it’s gone. Next week, you type it again. A Skill is the packaged, persistent version of that instruction. Write it once, and it’s there every time - for you, and potentially for everyone else at your organization who has access to it.