A D2C founder I know spent her Sunday night asking Claude a simple question: "Can I sell my retinol night cream in Germany and Italy?" Claude gave her three paragraphs of hedged generalities about "consulting a local regulatory expert" and a vague mention of EU cosmetics regulations. She ended up shipping anyway, got pulled from the Amazon DE listing six weeks later for a missing Responsible Person, and lost the Q4 launch window. Total damage: about €18K in inventory, ads, and rework.
That story is not unusual. It's the median experience for anyone trying to ship a regulated physical product across borders with an LLM as their first line of research.
So we did something about it. This week we open-sourced skills_library — 45 production-grade compliance skills for Claude Code, MIT-licensed, no signup, no telemetry. Below is what's in it, how it works under the hood, and why we chose to give the toolkit away while charging for the regulatory data API behind it.
What we shipped
Forty-five skills, organized into six verticals:
- Product compliance — cosmetics, food/supplements, electronics (CE, FCC), textiles, toys (EN71), medical devices
- Cross-border — EU CPR/CPNP, UK post-Brexit, US FDA/FTC, Canada, Australia, Japan
- Marketplace — Amazon, Shopify, TikTok Shop, Meta, Google Shopping policy alignment
- Privacy & data — GDPR, CCPA, cookie consent, DPAs, ROPA
- Corporate & IP — incorporation by jurisdiction, trademark filing, contracts
- Operational — labeling, batch tracking, recall procedures, customs codes (HS)
Everything lives in ~/.claude/skills/comply/ after a one-line install:
git clone https://github.com/Cleo-Labs-IA/skills_library.git ~/.claude/skills/comply
Restart Claude Code. You now have 40 new triggers available.
The SKILL.md format, briefly
If you're new to Claude Code skills, the mechanism is delightfully simple. A skill is a folder with a SKILL.md at its root. The file has YAML frontmatter and a body. Claude reads the frontmatter at session start and uses the description field to decide when to auto-trigger the skill.
Here's a trimmed example from comply/product-compliance/SKILL.md:
---
name: product-compliance
description: "Use when a user asks whether a physical product"
can be sold in one or more jurisdictions, what labeling or
certifications are required, or what regulatory body governs
it. Covers cosmetics, food, electronics, textiles, toys,
medical devices.
triggers:
- "can I sell"
- "regulatory requirements"
- "CE marking"
- "FDA"
---
# Product compliance
When invoked, you MUST:
1. Identify the product category (cosmetic, food, electronic, etc.)
2. Identify all target jurisdictions
3. For each (category, jurisdiction) pair, call the Cleo Legal
API tool `get_regulation` to retrieve current obligations
4. Return a structured table with: regulation, authority,
required documents, estimated cost, timeline
5. Never invent regulation numbers. If a regulation is not
returned by the API, say so explicitly.
The triggers are not hard rules. Claude weighs the description plus the user's prompt to decide. In practice, our descriptions are tight enough that the right skill fires 90%+ of the time.
How the MCP integration layer works
Skills give Claude a procedure. They don't give it data. For that, the skills call out to the Cleo Legal API over MCP.
Setup is one line:
claude mcp add cleo-legal-api \
--url https://legaldata-public.cleolabs.co/mcp \
--header "Authorization: Bearer $CLEO_LEGAL_KEY"
The API exposes tools like get_regulation, list_authorities, search_signals, and get_signal. Each skill knows which tools to call and how to format the output. You can use the skills without the API key — they'll degrade to "I don't have current regulatory data, here's the procedure you'd follow" — but the value lift with the API is significant: real regulation IDs, real fee schedules, real signal feeds from authorities like ANSM, BfArM, FDA, MHRA.
A skill calling into MCP looks like this in the body of SKILL.md:
For each jurisdiction, invoke:
mcp__cleo-legal-api__get_regulation(
product_category: <category>,
country: <ISO-3166-1 alpha-2>,
include: ["fees", "documents", "timeline"]
)
If the response includes `signal_ids`, follow up with
`get_signal(id)` for each one and surface any active alerts
to the user before the summary table.
That's it. No orchestration framework, no agent graph. The skill is a procedure, the MCP server is the knowledge, Claude is the runtime.
Multi-agent: parallel jurisdiction scans
One of my favorite skills in the bundle is multi-jurisdiction-scan. Given a product and a list of target markets, it dispatches one sub-agent per market in parallel, each running the product-compliance skill scoped to its jurisdiction, then merges results into a single table sorted by go-to-market difficulty.
The pattern:
When invoked with N jurisdictions:
1. Dispatch N parallel Task agents, one per jurisdiction.
2. Each agent runs the product-compliance procedure for its
single market and returns a structured JSON block.
3. Wait for all N to complete.
4. Merge into one comparison table with columns:
jurisdiction | regulations | est. cost | est. timeline |
blockers | recommendation
5. Highlight the easiest 3 markets to launch in first.
Running this against 8 EU countries takes about 90 seconds end-to-end. The same task with a regulatory consultant: two weeks and €15K.
Why open source it
The honest version of the answer: it's the cheapest, most defensible distribution we can build right now.
Compliance is not a category most developers go looking for. Nobody Googles "compliance skill for Claude Code." But every D2C founder, every Shopify agency, every solo operator running ads on Meta hits the same wall the moment they try to expand to a second country. If our skills are the default thing that comes up when an AI agent encounters that wall, we win — even if 95% of users never pay us a cent. The 5% who do pay (for the API, the Pro plan, the regulatory signals feed) more than cover the engineering cost of maintaining the skills.
There's also a quality argument. Open-sourcing forces us to write skills that are legible, auditable, and correct. A black-box SaaS can hide behind "trust us." A public MIT repo cannot. If we ship a skill that says "Germany requires a TÜV mark for textile imports" (it does not), someone will open an issue and roast us in public. That accountability is good for us.
What's next
A few things are queued up:
- More verticals. Pet products, alcohol, CBD, supplements with novel ingredients. Each one is two to four new skills.
- Signal subscriptions. A skill that subscribes to regulatory updates for a product and pings you when something changes. Already half-built.
- Localized output. Right now everything outputs in English. French, German, Spanish, Italian are next — the regulations themselves are obviously in local language.
- Community skills. We want pull requests. If you've shipped a product in a jurisdiction we don't cover, write the skill and submit it.
How to contribute
The repo has a CONTRIBUTING.md with the skill authoring checklist. The short version:
- No vague language. "May require certification" is banned. Either it does or it doesn't.
- Cite the actual regulation. EU 2017/745 not "EU medical device rules."
- Include cost ranges in EUR. We'd rather be wrong by 30% than absent.
- Test on real product cases. Each skill folder has an
examples/directory.
Open an issue first if you're proposing a new vertical. We'll help scope it.
CTAs, since you read this far
- Star and clone the repo: github.com/Cleo-Labs-IA/skills_library
- Get an API key for live regulatory data: legaldata-public.cleolabs.co (€349/mo, free 7-day trial)
- More context on what we're building at cleolabs.co
If you build something with the skills, I want to see it. Drop a comment, open a discussion on the repo, or email me directly. Especially interested in what breaks — every reported failure is a sharper skill in the next release.
— Naomie Halioua, founder, Cleo Labs
