Most agent-skill libraries never mention licensing. That's fine until the work is billable — then it's the one thing you needed to have checked first.
Here's the audit to run before you use any skill, prompt pack, or agent workflow on paid client work, plus two adjacent decisions (disclosure, and how to structure skills across clients) that trip people up even after the license is clear.
1. Find the actual license, not the marketing page
A product page saying "great for freelancers" is not a license grant. Look for the license file or terms page and check for three specific permissions, because a generic "free to use" claim usually doesn't cover all three:
- Commercial use — can the output be used in work you're paid for at all?
- Client delivery — can you hand the output to a third party, or does the license only cover your own internal use?
- Modification — can you adapt the skill's instructions to a client's specific context, or does it have to run unmodified?
The failure mode is discovering a "personal/non-commercial use only" clause after you've already delivered the work. At that point you have no clean option — pull the deliverable, renegotiate, or knowingly keep using something you're not licensed for.
2. Know what's actually prohibited, because it's rarely "everything"
Most commercial-friendly licenses draw the line at resale of the tool itself, not at using it. That's a meaningful difference:
- Using a skill to produce client deliverables → typically fine
- Modifying a skill's instructions for a client's stack → typically fine
- Repackaging the skill pack itself and selling it as your own product → typically the one thing prohibited
If a license is silent rather than explicit on client delivery, treat that as a red flag, not a green light. Silence isn't permission — it's a term nobody wrote yet, and you don't want to be the test case.
3. Decide your disclosure policy before a client asks
This isn't a licensing question but it comes up in the same conversation, so decide it in advance rather than improvising when asked. Two positions that hold up:
- Disclose that agent-driven procedures are part of how you deliver, framed as a reliability claim ("this runs the same documented process every time") rather than a confession.
- Don't disclose tool-level detail, but stand behind the output exactly as you would work you typed by hand.
What doesn't hold up is deciding this reactively, mid-engagement, because that reads as evasive regardless of which position you land on.
4. Structure skills as shared procedures, not per-client copies
Once the license is clear, the operational mistake is duplicating a whole skill set per client instead of parameterizing one. Concretely:
- Keep one hardened set of workflow skills (the actual procedure — steps, checks, output format).
- Vary only the project-level context per client (their stack, their brand voice, their specific integrations).
Fork the whole skill per client and you'll eventually fix a bug in client A's copy and forget clients B through Z have the same bug. That's not a licensing risk, it's a maintenance one, and it's the more common way agencies actually get burned.
The one-line version
Check commercial-use, client-delivery, and modification rights explicitly before you bill against a skill — don't infer them from a landing page. Decide disclosure once, not per-client. And keep procedures shared, context per-client, so you're maintaining one system instead of a growing pile of forks.
If you're running licensed kits already, most of the packs built for exactly this (client-delivery, resale-of-the-tool-prohibited) will say so up front rather than making you dig — that's worth checking before you assume you have to build your own from a free collection with no license page at all.
Top comments (0)