the project
About Skyl
skyl, like skill. A composable registry of rules for AI coding agents, where every rule had to earn its place by measurement rather than by sounding right.
What it is
What it is
A registry of rules for AI coding agents, split along five axes so a project loads the intersection that applies to it. 13 skills and 146 rules today, all of them Android, which is one family of an intended many.
What problem it answers
Most published agent skills are one large file covering a whole domain, so most of what they contain is irrelevant to any given project and is paid for in context on every request. Loading all 13 of these costs about 20,200 tokens. A real project loads four or five of them.
What makes a rule admissible
That a model gets it wrong without being told. Not that it is true: most published skill content is true. Every rule here was put in front of a model that had not been told it, and kept only if that model got it wrong.
What that costs
17 rules have been removed because a control arm already did the right thing unprompted. Retiring rules is the load-bearing part: a rule a model already follows spends context and buys nothing, and as models improve, more of them expire.
The mechanism is on how it works, the format on the spec, and what was actually run on evidence.
The bar
A rule ships only if it passes four tests, in order. Three of them are ways of saying no.
- Does the model get this wrong unprompted? If it already does the right thing, the rule displaces one that would have worked.
- Does a linter or the compiler already catch it? Then it is not the agent's problem.
- Would 900 of 1000 projects hit it? Interesting is not the bar.
- Is it checkable at every token, or an action deferred to later? Deferred actions are not rules, which is why there are no checklists here.
The finding that shapes everything: corpus support is an anti-signal. The more repositories that document a practice, the more likely a model already follows it, because the corpus and the training data are the same material. Rules drawn from what everyone writes down measure nothing. Every confirmed result here came from a control arm or a primary source, never from how often a practice appears in public code.
What it will not do
- Install anything without asking. Every command prints what it would write first.
--yesexists for scripts that already know. - Ship a rule nobody can check. An instruction a reader cannot hold against a file and answer yes or no is not admitted.
- Ship a rule with no boundary. Every rule says where it stops applying. Their absence is what turns a rules file into a nitpick generator.
- Keep a rule because it was expensive to write. A control arm that already does the right thing retires it, and 17 have gone that way.
- Send the reasoning to your model. The why, the pitfalls and the evidence stay in the registry for you to read. Only the rules are installed.
What it costs you
Nothing, and there is no account. Both repositories are MIT licensed and the CLI is on npm.
- No telemetry. The CLI makes exactly one network request, to
skyl.dev/registry.json, and only when you pass--refreshor have no bundled copy. There is no analytics anywhere in it. - No account, no key. Nothing here authenticates you, so there is nothing to sign up for and nothing to leak.
- This site runs no analytics. It loads a webfont from Google Fonts, which is the only third party a page here talks to. Everything else is served from this domain.
- Context, which is the real price. Each skill states its token cost before you install it, and
skyl listtells you what you are carrying.
Who made it
One person, ahmmedrejowan, who is named on every skill file and accountable for it.Skills carry their author in the file, and contributors lists who wrote what.
The most useful thing you can do here is prove a rule wrong. Every rule is a falsifiable claim that a model fails without it. If you have a control run where the model already does the right thing, that rule should go, and 17 have gone exactly that way. How to send one.
Where it is
Pre-alpha. One family is published and measured. The spec is being written from it rather than ahead of it, so it describes what exists rather than what is planned.
Skill content is versioned and the CLI records a hash of what it wrote, so an upgrade is a diff you can read rather than a surprise. What is not stable is the shape of the registry itself: axes, family naming, and how a service layer composes are all still moving.