Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · September 7, 2026 · repo

sv-number/skillsAgent Skills specificationai-skillsagent-securityclaude-codecodex

sv-number/skills and the Agent Skills Supply Chain: What a SKILL.md Actually Installs

A 336-star repo hands your agent a phone number in 200-plus countries and reads the SMS code back. Its restrictions are a paragraph of prose, and the company being paid per activation wrote them.

The README opens with a scenario and a solution in four lines:

> Read the sv-number skill and register me a Telegram account on an Indonesian number.

  ordered +62 838 1234 5678
  code 123456
  account created

Underneath it, one sentence: "One markdown file. No SDK, no dashboard, no human at the keyboard."

That last clause is the product. sv-number/skills is a single SKILL.md plus two example scripts that teach an agent to rent a real phone number for the duration of one signup, in whichever country the target service expects, poll for the verification code, and hand the number back. Trendshift's live-mentions board surfaced it this week. It carries 336 stars, 44 commits, two forks, an MIT license, and no releases. Of its fourteen GitHub topics, the ones that tell you who it is aimed at are claude-code, codex, anthropic, claude-skill, phone-verification, and sms-verification.

I have read a lot of skill files this year. This is the best-engineered one I have found, and reading it carefully changed how I think about what installing a skill actually does.

The stakes: a skill is a dependency you cannot audit the way you audit a dependency

Here is the thing about the Agent Skills format that I do not think has landed yet.

Per the specification, an agent loads a skill's name and description at startup for every installed skill, roughly 100 tokens each. The full SKILL.md body loads when the skill activates, with under 5,000 tokens recommended. Scripts and reference files load only when needed. That progressive disclosure is good design and it has a consequence: the description field, up to 1,024 characters, is permanently resident in your agent's context, and it is written by whoever wrote the skill.

Now look at the enforcement surface. Scan the spec's frontmatter table for a field that constrains what a skill may do, and there is exactly one: allowed-tools, a space-separated string of pre-approved tools, marked experimental, with support that "may vary between agent implementations." Everything else in a SKILL.md is prose. The body has "no format restrictions. Write whatever helps agents perform the task effectively."

So a skill is a dependency whose entire behavioral contract is natural language, aimed at a model, written by a party with an interest in the outcome. You cannot type-check it. You cannot lint it for capability. You read it, or you do not.

Most people do not.

The substance: this skill is genuinely well made, and that is the interesting part

I want to be precise here, because the easy version of this article is a dunk, and the easy version would be wrong. The technical work in this file is better than most vendor documentation I pay for.

A few examples of what I mean.

It reports measurements, with dates. The number lives about 20 minutes, and rather than saying so vaguely, the file says an unused activation was still STATUS_WAIT_CODE at 20.9 minutes and had expired by 21.1, measured 08 August 2026. That is a maintainer who actually ran the thing with a stopwatch.

It documents a currency trap that would silently cost you money. The lang parameter sets the response currency, and leaving it out does not fail loudly. The file gives the receipt: the same balance came back as 3188.81 with lang=en and as 270.20 with no lang at all, checked 07 August 2026. Read prices in one currency and pay in another and every comparison you make is wrong.

It refuses to let you misread its own metric. The API returns a deliverability field per service and country. A naive integration would treat zero as "nothing gets through." The file says, in bold, that a zero means "no statistics yet," notes that the field was populated for 74 of 3,835 pairs on 07 August 2026, and tells the agent to fall back to pool size when the number is missing. Very few vendors will tell you their own headline metric is mostly empty.

It warns about its own foot-guns by name. Service codes are short and arbitrary, so the file lists the ones that will burn you: uk is Airbnb, not the United Kingdom. re is Coinbase, tn is LinkedIn, mt is Steam, lf is TikTok, dr is ChatGPT. Match on the service name, not the code, and search the bare name because discord finds it and discord.com does not.

It handles the second factor honestly. When a service asks for an authenticator code after the SMS step, the file explains that TOTP is RFC 6238, ships a twelve-line Python implementation, and instructs the agent to compute the code locally and never paste a TOTP secret into a third-party website, "because whoever holds it holds the second factor forever." That is correct security advice, given away for free, in a file selling a competing service.

The whole thing is careful, specific, and clearly written by someone who has run the API in anger. If I were grading SKILL.md files on craft, this one wins.

The part where the craft becomes the problem

Now read the restrictions.

Under a heading called "Being a good citizen," the skill says: use one number for one purpose, "don't register accounts on services that forbid it, and don't touch banking, payment or government services with a temporary number." The README's "What it is not" section repeats it: these numbers do not send SMS, do not take calls, and are not for banking, payment, or government accounts.

Those are the right restrictions. They are also, mechanically, three sentences of English in a markdown file, sitting inside a document whose stated purpose is teaching an agent to clear phone-verification walls, published by SMS SERVICES PTE. LTD., which is the name in the MIT license header and the operator of the paid API the skill calls. There is no free tier. Every activation is revenue.

I do not think that is a scandal. It is a business, it is disclosed, and the disclosure is unusually clean: the README's closing line is "MIT for the skill and the examples. The service behind it is commercial." I have seen far worse hidden far deeper.

What I think it is, is the clearest illustration available right now of what a skill file is. It is a distribution format for a vendor's judgment about when you should use their product, and that judgment loads into your agent's context at startup and stays there. The description field on this one says to use it "when an agent has to pass a phone check during signup, login or account recovery." That sentence is now a standing invitation in the agent's head, and the restraint on it is a paragraph two thousand tokens further down that the model reads once, on activation, alongside everything else.

Prose is not a permission system. The one field in the spec that is a permission system is marked experimental.

Put this into practice

You do not need to have an opinion about this repo to get value out of it. You need a habit for reading skills. Here is the one I now use, and it takes about five minutes per skill.

1. Read the description field first, alone, and ask what it authorizes. This is the only part that is always in context. Strip away the body and ask: if my agent knew nothing else about this skill, what situations would this sentence pull it into? Write that down. If the answer is broader than what you wanted, the skill is miscalibrated for you no matter how good the body is.

2. Grep for who gets paid. Search the file for a domain, an API key variable, a signup link, a pricing page. grep -nE "https?://|API_KEY|pricing|register" SKILL.md will find it in one pass. A commercial skill is not disqualifying. An undisclosed one is.

3. Separate the capability claims from the restraint claims, and ask what enforces each. Capability claims are usually enforced by the API: if the file says getNumber returns ACCESS_NUMBER:ID:PHONE, you will find out fast whether that is true. Restraint claims are usually enforced by nothing. Anything in the "rules" or "guidelines" section of a skill file is a suggestion to a model, not a constraint on a system.

4. If you install it, enforce the restraints yourself, outside the file. For this one, that means egress policy: the skill needs outbound HTTPS to exactly one host, sms-verification-number.com, and its own compatibility field says so. If your harness supports network allowlisting, that is a real boundary, and it is stronger than any sentence in the markdown. Similarly, if your runner supports allowed-tools, pin it, and treat the experimental warning as a reason to verify the behavior rather than a reason to skip the field.

5. Watch the MCP variant separately. The file also offers the same nine calls as an MCP server, installed with claude mcp add sv-number --env SVN_API_KEY=your_key_here -- npx -y sv-number-mcp. That is a materially different trust decision from copying one markdown file: an MCP server is executable code pulled at run time through npx -y, from a separate repository, holding your funded API key. If you were comfortable with the skill, do not assume that comfort transfers.

6. Do the reading for the skills you already have. Most people who install plugins liberally are carrying a dozen description fields into every request without having read one of them. Start with the ones that touch the network or spend money.

Honest limitations

I have not run this API. Everything above about the API's behavior comes from reading the repository at commit-time on 7 September 2026, plus the star count and license verified against cache-busted sources. The measured claims in the file, the 20.9-minute expiry, the 3188.81 versus 270.20 currency discrepancy, the 74-of-3,835 deliverability coverage, are the maintainer's own measurements from early August, reported by the maintainer, unverified by me. They are unusually specific for invented numbers, which is evidence and not proof.

This is not a security disclosure and the repo is not doing anything covert. Phone-verification bypass services have existed for a decade and are trivially findable. The genuinely new thing here is the packaging, meaning that the integration effort has gone from "write an API client" to "point a runner at a directory," and that the resulting file lives in the same context window as everything else your agent knows.

I am also not neutral about the underlying use. There is a legitimate reading of this, and the skill states it: registering on a customer's behalf in the country a service expects, keeping their personal number out of a database that will eventually leak, and testing your own signup flow in every market you ship to without buying SIM cards. Those are real. They also sit in the same file, one heading apart, from "verify a batch of accounts across countries." The file does not draw a line between them because a markdown file cannot draw a line between them. Only your harness can.

And a skill file's restrictions being unenforceable is not this vendor's fault. It is a property of the format. Every skill you have installed has the same gap. This one is just legible enough to see it through.

What to do with this

Pick the skill in your setup that touches the outside world most directly. Open its SKILL.md. Read only the description field, then close the file and write down what you think that one sentence authorizes your agent to reach for.

Then open the file again and read the rules section, and ask yourself what would happen if the model skipped it.

That gap is your actual security posture. Everything else is documentation.

Sources: sv-number/skills README, the skill file itself, Agent Skills specification.

Medium metadata

  • Title: sv-number/skills and the Agent Skills Supply Chain: What a SKILL.md Actually Installs
  • Subtitle: A 336-star repo hands your agent a phone number in 200-plus countries and reads the SMS code back. Its restrictions are a paragraph of prose, and the company being paid per activation wrote them.
  • Tags: AI Agents, Claude, Security, Open Source, Software Development
  • Suggested kicker image: a markdown file rendered as a contract with the signature line blank
  • Canonical: import from the fervorai.dev URL after publish