Point an AI assistant at API documentation and ask it to do something useful, and it will. It will also do it slightly differently every time, invent conventions that look reasonable, and make one or two mistakes that are obvious to anyone who knows the domain and invisible to anyone who does not.
We published a file to fix that. It is on GitHub, it is Apache-2.0, and it is a couple of hundred lines of Markdown.
What a skill actually is
A skill is a document your assistant reads before it starts work. Ours is a
SKILL.md, and it carries three things: the workflow (what to call, in what order),
the vocabulary (what a signal is, what a model is, why those are not the same word), and the
guardrails.
The guardrails are the part worth talking about, because they are not written for you.
The bugs an agent will confidently produce
Here is the one that convinced me this needed writing down.
Ask our API for signals without naming a date and you get the most recent released board. Before the morning release, that is yesterday’s. Which is correct behavior — but an assistant that does not know it will fetch a board at 8:40 AM, see a full list of signals with a date attached, and cheerfully report today’s plan. Wrong, confident, no error anywhere.
No amount of model intelligence prevents that. It is not a reasoning failure; it is missing domain knowledge, and the only fix is to write it down where the agent will read it. So section 0 of the skill says:
Check the date before treating a board as actionable. With no?date=,/signals.phpreturns the most recent released board — which before the morning release is yesterday’s.
Two more live in the same section.
Verify the key first. Every session opens with GET /me.php, so a revoked
or mistyped key fails loudly at the start instead of quietly returning an empty board twenty
minutes later. An empty board looks exactly like “no signals today.”
Know what you are fetching. A signal is one model’s UP or DOWN call on one ticker for one trading day. It is not a standing position, not a price target to chase, and not advice. An assistant that treats it as any of those three will do something you did not ask for.
Each of those is a mistake a capable assistant makes for the first time in production, on your account.
Why it is public
Two reasons, and the second is the real one.
The practical one: if every subscriber’s agent improvises against raw docs, every subscriber gets a slightly different product, and the ones who get it wrong will quite reasonably blame us. A shared file makes behavior consistent and fixable in one place.
The real one: we are a publication. The ledger is public because you should not have to take our results on faith. The skill is public for exactly the same reason — you can read what we tell your assistant to do, including every guardrail and every point where we instruct it to hand the decision back to you. If we ever wrote something in there we would not want you reading, that would be worth knowing.
Apache-2.0. Fork it, gut it, throw out our guardrails and write better ones. It is your agent.
Where it is
github.com/tradedm/agent-skills
It is a SKILL.md and a reference.md — the second holds the
endpoint-by-endpoint detail the first does not need to carry. And if you only want to check
that your key works before wiring anything to anything, that is one line:
curl -H "Authorization: Bearer tdmk_YOUR_KEY" \
https://tradedm.com/api/v1/client/me.phpIf that comes back with your key’s label and the number of signals it unlocks, you are connected.