Most of what shapes a small project is what it does not contain. These were real options, and each was turned down for a reason worth writing down. If one of them was the wrong call, that is worth knowing.
v1 offered one file with all four skills concatenated. It was removed rather than renamed, because it could not be installed anywhere: each skill has to be its own SKILL.md in its own folder, so a combined file was a document about skills rather than a set of skills. A per-platform “install all” command would work, but it would have to pick a platform, and the ordering would quietly favour one tool over the others.
There are four. A skill that fires on everything stops meaning anything. One idea got close: /health — is this session still healthy enough to continue? It is a useful question, and notably not about code at all. It is recorded here rather than shipped, mostly as a reminder that a set of skills should not quietly assume every problem is an engineering problem.
The homepage invites you to describe your problem in a text box, and promises that what you type stays in your browser. That promise is worth more than knowing which words people type. The cost is real and worth stating plainly: there is no way to tell whether any of this is working.
Not on principle — on architecture. The most checkable claim this site makes is that it makes no third-party requests and stores almost nothing. An embedded signup form means a provider, an endpoint, a privacy notice, consent handling and unsubscribe plumbing, and it makes someone responsible for other people’s personal data. That trades the site’s simplest promise for a list that might never be mailed, and a list you do not mail is worse than no list. The changelog feed does the same job with none of it.
The “which one” box scores what you type against a keyword list for four skills, in the page. Ranking would be worth building over a large catalogue. Over four items it would mostly be a more impressive way to be wrong.
Skill versions are typed by hand into the frontmatter. That is the whole system, on purpose — the right amount of machinery for files that change rarely. If that stops being true, it is the first thing here that will need to grow.
You can change a skill’s defaults here and download the result. Those changes are not saved, and there is no link that encodes them, because that would mean either a backend or a very long URL. The file you download is the artefact — keep it, edit it further, put it in version control. It is yours at that point, and this site is not part of the loop.
A place for people to talk to each other is a commitment to moderating it. The repository has an issue tracker, which is the right amount of surface area for a project this size.
Ogilby’s Britannia of 1675 drew a road as a ribbon — only what you pass, useless for any other journey and far better than a real map for that one. Sailing directions do the same in prose: bearings, depths and landmarks in order. The context problem has exactly that shape. Most of the effort goes into handing an agent the territory, the whole repository or the whole document set, when the task only wants the route. None of the four asks that question: /spec establishes the goal, and /kiss deliberately limits itself to code and structure.
It is the strongest candidate for a fifth skill so far, and it is written down here rather than built, for two reasons. A rutter is something you write, where the other four ask a question and return a verdict — so it would have to be reshaped into are we carrying the territory when the task wants the route?, which is a narrower idea than the one that was interesting. And it is untested. Four skills that each say something specific are worth more than five where one is a guess. If this is the wrong call, it is the entry on this page most likely to be wrong.
This list is not a roadmap. If something here should have been built, or was turned down for a bad reason, the issue tracker is the place to say so.