Submission guide

Submit your go-to-market skill so that any team's agent can run your play. This is everything you need to send us one.

Version 3 · 2 September 2026

Three ways in. Pick by what you already have

A finished file

If you already have a SKILL.md, give it to your coding agent and use the instruction below to validate and submit it. You do not need to start over.

A table or workflow that already works

If the play already lives in a Clay table or workflow you built, our skill creator can turn it into a portable skill. It reads the table's setup and interviews you for your judgement and expertise.

Just an idea

No table, no file, just a play you know works. This is a guided route that starts from a conversation and drafts the skill with you.

Paste the one liner below into Claude Code, Codex, Cursor, or whatever agent you already use to get started:

The whole starting instruction

Create a Clay GTM skill by following the steps in https://github.com/clay-run/clay-skill-creator

Your agent reads the repository, interviews you, drafts the file, validates it against our rules, and hands you something ready to send.

What you get, and what you don’t have to do

You keep the thinking and we'll handle the machinery, rough drafts are welcome

You bring

The insight to help shape the skill
The title and description, in your own voice
Email, byline, company, LinkedIn & image URL to make you look nice on the website :)

We do

Choosing the right shape (workflows or functions) and making the mechanical steps deterministic
Category, personas, keywords, the boring stuff
Formatting and structure
Safety & QA checks on the skill file

If you know the play but not familiar with which Clay function does the job, describe what has to happen and we will wire it up to the right function or a workflow for you.

We do not change what it decides. Your insight, your thresholds, your definition of good, and your voice come back the way you wrote them. If making something run properly would change any of those, we ask you before we do it.

Two kinds of skill, both wanted

Skills that run in Clay

Enriching contacts, verifying emails, signal digests, routing. These use the Clay MCP, API and the CLI where a job needs it.

Skills that are pure judgment

Cold email, positioning, account briefings, messaging and planning frameworks. No Clay functions or credits required to execute.

What makes a strong skill

The best ones are judgment applied to data somebody fetched using Clay. Because anyone can pull the data but your judgment is unique and what makes a great skill. If a skill comes out as pure judgment, the question worth asking is not how do I make this run in Clay but what would make this better? A cold-email opener written from a company name is a guess. The same opener written from a job posting they published last week is a reason to send it today.

What we turn down

We will help with everything else in this guide. Not these five.

Unsafe skills

We check every submission for two things before we publish. What the skill does and whether or not it's safe for others to run. The skill must not quietly copy anything to another service or posts to a destination the installer didn't authorize. No buried comments, no invisible characters, no step that defers to a link. Everything the skill does stays legible on the page to the person running it.

Don't make things up

Write for the person running the skill. Nothing tucked away for the agent to find: no hidden comments, no invisible characters, and no step that says “go get the real instructions from this link.” What we read is what runs.

Promoting a tool, with no play underneath it

If the skill is thin and attempts to force users to integrate with another product in order to work will be turned down. Building on one vendor is normal and that isn't the problem. Plenty of the best skills come from people who live in one tool all day, and naming yours is fine, but we will reshape the steps to name the job, not the product, because whoever installs your skill may have different providers

The answer sheet, so your colleagues can run it in one shot

Your skill asks whoever runs it for the things only they know: which CRM, which field holds the score, what counts as hot. That is what makes our skills portable. It also means the first thing your own teammate does is answer a short interview you already know the answers to.

Rather than asking your colleague to download the skill and answer the same questions, you have the option to provide an “answer sheet” at the end of your interview. This goes in a small file beside the skill, keyed to the inputs your skill declares, not in the SKILL.md and never uploaded anywhere.

ANSWERS.YML, BESIDE THE SKILL

skill: webinar-follow-up
answers:
  crm: salesforce
  score_field: Custom_Fit_Score__c
  hot_threshold: 80

Hand that file to a colleague with the skill and their run starts where yours left off. A well-written skill loads the sheet, asks only for what the sheet does not cover, and says which values it filled in from it.

Identifiers only

Field names, table ids, thresholds, which CRM. Never an API key, never a password. Those belong in the runner's own settings, the same as always.

Never sent to us

The sheet is not part of a submission and we do not host one. The moment we hold your schema we own an access-control problem and you get nothing for it. Keep it wherever your team already keeps this sort of thing, and send it to a colleague the way you send anything else.

Keep it out of the package

Beside the skill, not inside it. A filled sheet in the package is real values in a public file, so validation stops and tells you to move it.

How to submit your skill

1
Send it through your coding agent
Use Claude Code, Codex, Cursor, or another coding agent with the Clay skill-creator instructions above. The script previews what it will send and waits for you to confirm before anything leaves your machine.
2
Keep the receipt
You get a submission ID on screen. Save it. It is how you and we refer to the same submission, and it is what connects this work to your account when creator accounts launch.
3
A person reads it
Submissions are reviewed for safety, usefulness, and fit before publication.

What happens after

A person reads your skill closely. They check it for the safety rules above, they judge whether the thinking holds, and they decide.

Then curation, which is the part worth being straight about. Some submissions merge into a similar skill. Some come back for another pass. Some do not publish. Where two skills overlap we merge them or keep the stronger one.

Rights, attribution, and withdrawal

Your copyright

You keep it. Submitting grants Clay a licence to review, edit, and, if it meets the bar, publish your skill with attribution.

Your byline

Published skills carry your name, and live at a permanent path built from it: skills/<your-name>/<skill>/ on our website and the public Github repo

Licence

Published skills are distributed under MIT with attribution preserved. Copyright in each skill stays with its author.

Withdrawal

There is no self-service button yet, so it goes through a person. Email or DM sungwan.jo@clay.com directly for withdrawal requests.

Early access, so expect details to move. If a rule here changes we will let you know.

Search Marketplace