Most first submissions to emdly are a good prompt in a .md file. They get sent back, not because the prompt is bad, but because a prompt and a skill are different things. A prompt is what you say once. A skill is what you hand to someone else's agent and trust it to do the same job next month.
Four sections
Every skill that comes out of review well has these, in roughly this order.
When to use. Two or three bullets that say what triggers the skill and what does not. "On every new ticket in the support inbox" — and, just as useful, "not for tickets already assigned to an engineer". An agent choosing between skills reads this section first.
Process. Numbered steps, each one an action the agent can take. Put the judgement calls here explicitly: "If the customer names a competitor, tag competitive and stop; do not answer pricing questions." The more a step reads like an instruction to a careful new colleague, the better.
Rules. The short list of things that must always or never happen. Keep it short — ten rules are read, forty are skimmed. "Never invent an order number." "Quote the customer's own words in the summary."
Output. The exact shape of the result: a fenced block with the fields, or a filled-in example. This is the part people skip and the part that matters most. An agent with an output contract produces the same shape every run; an agent without one produces prose.
The parts that are not optional
A title as the first heading, so the catalog and the agent know what the file is. A license — ## License with MIT under it is enough, and MIT is what we recommend. Without a license the automated check rejects the file before anyone reads it; a skill is code other people run.
Under 200 kB, plain Markdown, no HTML comments carrying instructions. Hidden instructions are the fastest way to get blocked by the safety scan, even when they are harmless.
A template
# Ticket triage
One line on what this does and for whom.
## When to use
- On every new ticket that lands in the inbox.
- Not for tickets already assigned.
## Process
1. Read the ticket and the customer's last three messages.
2. Classify: bug / question / billing / feature request.
3. Set priority from the table below.
4. Draft the summary in the output format.
## Rules
- Never invent an order number or a date.
- Quote the customer where the summary makes a claim.
## Output
```json
{"category": "...", "priority": "P1|P2|P3", "summary": "..."}
```
## License
MIT
Fill it in with what you actually do, remove the bullets you do not need, and submit. Review takes a day; the reasons for a bounce are written on My skills, and a fixed resubmission runs the same pipeline as the first.
Before you submit
Read the file as if you were the agent and had nothing else. If a step needs context that is not on the page, either add it or move it to your Brain — that is what the Brain is for. If the output section could be interpreted two ways, it will be.