LuluSkill
MenuClose
EN
Language
繁體中文

Language and theme are saved in this browser only.

Start with a goal

LULUSKILL ARTICLE

Before you use someone else's AI Skill: licence, permissions and source

How to check where a Skill or prompt pack came from, what its licence lets you do, what it asks to touch, and which red flags mean stop — with one evaluation worked through.

Written by LuluSkill — first-party content for this site

About 19 minutes to read

·

What this article is, and is not

This is LuluSkill's own writing. It does not quote, mirror or summarise any third-party Skill, and it recommends none. Reading it builds, publishes and runs nothing: what an AI tool does with your text is for you to check.

What you are really adding when you use someone else's Skill

A Skill, a prompt pack or a small agent tool is someone else's work, packaged so that your assistant can follow it. Sometimes it is only text: instructions, examples and a few rules. Sometimes it also carries scripts, settings and a list of things it wants to be allowed to do. Either way, once you add it, your assistant treats its words as part of the job you gave it.

That is why the useful question is not "is the author trustworthy?", which you usually cannot answer, but "what exactly am I adding?", which you can. Four facts answer it: where the Skill came from, which exact version you have, what its licence allows, and what it asks to touch. None of them requires reading code, and each can be written down in a sentence.

This article names no Skill and recommends none. Everything below is a way to judge one yourself, wherever you found it, including on this site.

If the word Skill itself is new to you — what the folder holds and which assistants read it — start withWhat are AI Skills (Agent Skills)? How SKILL.md works, and how to use one safely

Four facts to find first

In plain words

Source
The original place the Skill is published and maintained, usually a source repository — not a copy pasted into a post or a message.
Pinned version
A version that cannot change after you have read it: a numbered release, or one specific commit — a fixed snapshot in the repository's history. "The latest" is not a pinned version.
Licence
The written terms that say what you may do with someone else's work: use it, change it, share it, or sell something built on it.
Permission
Something the Skill needs your assistant or computer to be allowed to do: read files, change or delete them, reach the internet, run commands, or send messages as you.

Where it came from, and which version you have

Skills travel. One that starts in a source repository gets copied into forum posts, shared documents, chat groups and other people's collections, and each copy can be edited on the way. A copy is not a source: you cannot tell what changed, who changed it, or whether it is still the text the author published.

Versions matter for the same reason. If you evaluate a Skill today and it changes tomorrow, your evaluation describes something you no longer have. Writing down the exact version is what keeps your decision true.

Find the source in this order

  1. Start from wherever you found it and look for a link back to an original repository. If there is none, that is already an answer.
  2. Open the original and compare it with your copy. The same words in the same order is what you are hoping for; any extra line deserves a closer look.
  3. Look at who maintains it and when it last changed. A Skill nobody has touched in years may still work, but nobody will fix it for you.
  4. Choose one numbered release or one commit, and write its identifier down together with the date you looked.
  5. From then on, use that version and no other. When a newer one appears, evaluate it again rather than assuming it is the same.

Signs the source is weak

  • It exists only as a block of text in a post, with no original to compare it against.
  • Your copy and the original differ, and nobody explains why.
  • The instructions tell you to fetch something else from a different address before it will work.
  • You are told to always use "the latest", and there is no way to name the version you evaluated.
  • The maintainer changed recently, and large changes followed straight after.

What the licence lets you do

Being public is not the same as being yours to use. Something anyone can read on the internet is still someone's work, and what you may do with it is set by its licence. If there is no licence at all, assume the default is that you may look at it, and not much else.

You do not need to be a lawyer for a first check. You need to know what you plan to do, find the licence text, and see whether the two agree. When they clearly do not, or you cannot tell, that is the moment to ask the author or to leave it alone. Nothing in this article is legal advice.

Kinds of licence you will meet, in plain words

In plain words

Permissive
You may use, change and share it, usually as long as you keep the author's copyright and licence notice with it.
Share-alike
You may use and change it, but if you share your changed version you usually have to share it under the same terms. What counts as "sharing" differs between licences, so read that part closely.
Restricted
Terms such as non-commercial or no-changes. They may allow personal use and still forbid what you had in mind for a shop or a client.
No licence
No stated permission. Read it and learn from it, but do not copy it into your own work or pass it on without asking the author.
Custom terms
Terms the author wrote themselves. Read them in full; they can say anything, including things no common licence says.

Check the licence against your plan

  1. Write down what you intend: use it yourself, use it at work, change it, share it, or build something you will sell.
  2. Find the licence file itself, in the original repository, at the version you pinned. A word such as "open" in a description is not the licence.
  3. Check whether it covers everything. Bundled files, images or examples sometimes come from elsewhere, under different terms.
  4. Note what it asks of you in return — usually keeping a notice, sometimes saying what you changed — and do it from the start.
  5. If your plan and the licence disagree, or you cannot tell, stop there: ask the author, or find another way.

What it asks to touch

A Skill that is only text asks for nothing directly, but it can still tell your assistant to do things: open files, look something up online, or write a message for you. A Skill that includes scripts or tools may ask for access outright. Either way, list what it would touch, and compare that list with the one job you want done.

The rule is the one you would use for your own project: every permission starts at nothing, and a permission is granted only when a step you can name needs it. A Skill that tidies up a list needs to read that list. It does not need the internet, your email or the rest of your files.

Permissions to look for, and the question to ask about each

In plain words

Reading files
Which folders, exactly? "Your documents" is not an answer; one named folder is.
Changing or deleting files
What will it change, can the change be undone, and does it work on a copy first? Deletion should never be a side effect.
Network access
Which addresses, and what does it send there? "It needs the internet" without a destination is not enough.
Running commands
Which commands, and why can the job not be done without them? This one permission can do almost everything else on this list.
Sending messages as you
To whom, with what content, and do you see each message before it goes? A message that has been sent cannot be taken back.
Keys and passwords
Why does it need them, and where will they be kept? A Skill that asks you to paste a key into its text is asking for the wrong thing.

Starting every permission at nothing is the same rule as the permissions grid for your own first version, explained inFrom a prompt to a first version: pages, data, permissions and the key flow

Red flags that mean stop

Most red flags have the same shape: the Skill wants more than its purpose explains, or it tries to change the rules your assistant works under. One kind deserves a name. Because your assistant reads a Skill's text as instructions, a line hidden in that text can steer it — to ignore what you asked, to reveal something, or to send something somewhere. This is often called prompt injection, and the defence starts with reading every line of instruction text yourself.

Stop and look again if it

  • Tells the assistant to ignore earlier instructions, keep something from you, or not mention what it is doing.
  • Asks you to paste a password, key or token into a prompt or into its own files.
  • Downloads and starts something else while it works, from an address it does not explain.
  • Contains text you cannot read: long encoded strings, oddly spaced characters, or instructions hidden in comments.
  • Asks for permissions its purpose does not need — a text formatter that wants the internet, a note-taker that wants to delete files.
  • Sends your data to a destination it does not name, or names one that has nothing to do with the job.
  • Hurries you: "run this now", "turn off your safety settings first", "approve everything to save time".
  • Claims to be official or endorsed, and you cannot find that claim anywhere except in the Skill itself.

A Skill that wants a key in its text breaks a wider rule about what never belongs in a prompt at all, covered inKeep secrets and personal data out of your prompts

One Skill, evaluated: a message for the volunteers

The example continues the invented food bank from the earlier articles. The sign-up page works, and the coordinator now wants help turning each week's shift list into a short, friendly message for the volunteers' group chat. Someone in a forum has shared a Skill that claims to do exactly that. Every detail below is invented for illustration.

The evaluation, fact by fact

Example

The coordinator works through the four facts before adding anything.

  1. Source: the forum post links to an original repository. Compared line by line, the forum copy has one extra instruction at the end that the original does not.
  2. The extra line tells the assistant to also send each finished list to an address nobody at the food bank recognises. That alone rules the forum copy out.
  3. Version: the original has numbered releases. The coordinator writes down the current one and the date, and evaluates only that.
  4. Licence: a permissive licence file sits at the top of the original. Using the instructions inside the food bank is within it, as long as the notice stays with any copy.
  5. Permissions: the instructions only need the shift list. But the package also holds a helper script that asks for network access and permission to post messages directly.
  6. The job is a draft message the coordinator will read and post by hand, so neither permission is needed. The script is left out; only the instruction text is used.
  7. Test: the coordinator tries it on an invented shift list with made-up names before the real list goes anywhere near it.

The dangerous part was one line long, and it was in the copy, not in the original. Comparing the two took minutes; finding out afterwards would have taken far longer, and the volunteers' names would already have gone.

The evaluation note, written out

Example

What the coordinator keeps, so the decision can be checked later — by someone else, or by the coordinator next year.

  1. What it is for: turning the weekly shift list into a draft message that I post myself.
  2. Source: the original repository — not the forum copy, which adds a line that sends the list elsewhere.
  3. Version: the numbered release that was current on the day I checked, and no other.
  4. Licence: permissive; keep the notice with any copy. Using it inside the food bank is covered.
  5. Permissions: reads the shift list I paste in. Network access and messaging are refused; the helper script is not used.
  6. Decision: use the instruction text from that version, and check again before moving to a newer one.

Every line is a fact someone else can check, and the note records what was refused as well as what was allowed.

A short evaluation checklist

Work through these in order. Any one of them can end the evaluation, and an evaluation that ends early is not a failure: it is the checklist doing its job.

  1. Write one sentence about the job you want the Skill for. Everything after this is measured against it.
  2. Find the original source, and compare it with the copy you found.
  3. Pin one version, and write down its identifier and the date.
  4. Read the licence file at that version against what you plan to do.
  5. List everything it would read, change, delete, reach or send, and cross out whatever your one sentence does not need.
  6. Read every line of instruction text yourself, looking for the red flags above.
  7. Try it on invented data, in a folder that holds only copies, before anything real is involved.
  8. Write the evaluation note, including what you refused, and keep it with your project.

Walk away when

  • You cannot find an original to compare with.
  • The licence does not allow what you plan, and the author has not said otherwise.
  • It needs a permission you cannot supervise, and the job cannot be done without it.
  • Describing the job yourself would take less time than finishing this list.

What LuluSkill's own rules require before a Skill is listed

LuluSkill holds itself to the same four facts, written as rules rather than advice. What follows describes those rules, so that you can hold any listing here to them.

Under those rules, a Skill may be listed only when each of the following has been recorded for the exact version shown, and a person has reviewed it.

The record behind a listing

In plain words

Source address
The original repository it came from, shown with the listing so that you can compare for yourself.
Commit
The exact, unchangeable snapshot that was read. A newer version is a new record, and is checked again.
Content fingerprint
A value calculated from the files themselves, so that any later change, however small, can be detected.
Licence and attribution
The licence detected in the source, and what it requires in return, such as keeping the author's notice.
Scan status
The result of an automated check of the text and files for patterns such as hidden instructions, embedded keys or shell commands — done by reading them, never by running them.

What those records do not mean

  • A clean scan is not proof of safety. It means the checks that were made found nothing; it cannot promise there is nothing to find.
  • A detected licence is not legal advice, and it applies only to the version it was detected in.
  • A missing record is shown as "not verified", never left blank and never assumed to be fine.
  • Nothing a Skill asks for is granted by default. Under the rules, every permission starts refused and is approved by you, one step at a time.
  • Files are never run while they are being read, listed or previewed.

The records do the same job as your evaluation note: they turn "this seems fine" into facts that can be checked. For your project, though, your own note is still the one that matters, because only you know the one job you wanted done.

Your next step

Three things to do with your own idea, in order. None of them needs an account, a tool or a Skill.

  1. Pick one Skill or prompt pack you are considering, and write the one-sentence job you want it for.
  2. Find its original source, pin a version, and read the licence file at that version.
  3. Fill in an evaluation note like the one above, including what you refused, before you add anything.